Description

In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-08-28T08:16:52.410Z",
  "pubdate": "2026-08-28T08:16:52.410Z",
  "executiveSummary": "The Linux kernel's perf tool contains multiple memory safety vulnerabilities within the register_pid() function, which is responsible for processing perf.data files.\nThese vulnerabilities include integer overflows, heap buffer overflows, and improper error handling involving BUG_ON assertions.\nThe flaws allow an attacker providing a malicious perf.data file to trigger out-of-bounds memory writes, potentially leading to arbitrary code execution or denial-of-service conditions.\nBecause perf.data is often treated as untrusted input when analyzed across different systems, these vulnerabilities pose a significant risk to analysts and automated processing pipelines.\nThe root cause stems from unchecked input sizes during buffer allocation and memory copying operations, compounded by unsafe error handling patterns that can result in memory leaks and inconsistent application states.\nNo specific authentication is required to trigger these vulnerabilities, as they are inherent to the processing of the data file itself.",
  "technicalDetails": "The register_pid() function in the perf sched utility suffers from a critical integer overflow vulnerability. When calculating the size for the task_desc pointer array, the expression (pid + 1) * sizeof(struct task_desc *) can wrap around on 32-bit systems if the pid value is sufficiently large (e.g., 0x40000000). This results in a call to realloc with an undersized buffer, followed by an initialization loop that performs out-of-bounds writes into heap memory.\nAdditionally, the function utilizes an unsafe strcpy operation when copying the comm string into the task->comm member. As comm is sourced from an untrusted perf.data file and lacks a length check against the fixed 20-byte COMM_LEN buffer, this allows for a linear heap buffer overflow.\nThe implementation also contains poor memory management practices. The code uses BUG_ON during allocation failures, which forces an immediate process termination instead of allowing for graceful failure recovery. Furthermore, the function incorrectly assigns the result of realloc directly to the pointer tracking the tasks, leading to memory leaks if the reallocation fails. The nr_tasks counter is also incremented prior to the reallocation, causing the internal state to become corrupted if the memory operation does not succeed.\nThe exploitation flow begins with the delivery of a malformed perf.data file. An attacker crafts a file containing a PID exceeding standard limits or an overly long comm string. When the perf tool parses this file, the register_pid() function processes these malicious inputs. The integer overflow triggers the undersized allocation, and the subsequent loop writes past the allocated bounds. Alternatively, the strcpy operation overwrites adjacent heap metadata or adjacent objects. By carefully controlling the heap layout, an attacker can achieve arbitrary read/write primitives, potentially escalating to remote or local code execution depending on the execution context of the perf utility. The lack of robust error handling ensures that even failed exploitation attempts can result in a crash, leading to a denial-of-service condition."
}