Description

The ELF core dump code counted the number of dumpable VM map entries, allocated a buffer for the corresponding program headers, then iterated over the map a second time to populate them. A process sharing the address space via rfork(2) can mutate the map between the two passes, causing the second pass to write program headers past the end of the buffer. An unprivileged local user sharing an address space with a process that dumps core can trigger an out-of-bounds write on the kernel heap, potentially leading to privilege escalation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-19T08:17:12.983Z",
  "pubdate": "2026-08-19T08:17:12.983Z",
  "executiveSummary": "A race condition vulnerability exists within the ELF core dump generation mechanism, specifically stemming from a time-of-check to time-of-use (TOCTOU) flaw during virtual memory map iteration.\nThe vulnerability allows an unprivileged local user sharing an address space via rfork(2) to mutate the memory map between the initial counting pass and the subsequent population pass.\nThis mutation causes a kernel heap out-of-bounds write due to a buffer size mismatch when writing program headers.\nSuccessful exploitation of this flaw can lead to localized privilege escalation, compromising the integrity and security of the affected operating system kernel.\nThe attack requires local execution capabilities and the ability to share an address space with a process that triggers a core dump.\nThe vulnerability represents a critical risk to system confidentiality and integrity, necessitating immediate remediation through official kernel updates.",
  "technicalDetails": "The vulnerability resides in the kernel subsystem responsible for generating ELF core dump files for processes.\nThe root cause is a race condition characterized by a multi-pass approach over the virtual memory (VM) map without adequate locking or synchronization.\nDuring the first pass, the ELF core dump code counts the number of dumpable VM map entries to determine the exact sizing requirements.\nBased on this count, the kernel allocates a memory buffer on the kernel heap specifically sized to hold the corresponding program headers.\nDuring the second pass, the kernel iterates over the VM map a second time to populate the pre-allocated buffer with the program headers.\nAn unprivileged local user leveraging rfork(2) to share an address space with a target process can concurrently mutate the VM map between the completion of the first pass and the execution of the second pass.\nBecause the VM map expands or changes between passes, the second pass attempts to write more program headers than the allocated buffer can accommodate.\nThis results in a heap-based out-of-bounds write condition within kernel memory, overwriting adjacent kernel heap structures.\nThe attack flow requires the local attacker to initiate a shared address space using rfork(2), coordinate timing with a core dump event in the target process, and dynamically alter the memory layout during the critical window between passes.\nPost-exploitation impact includes arbitrary kernel memory corruption, potentially allowing the execution of arbitrary code in ring 0 and leading to complete system compromise and local privilege escalation.\nNo network exposure is required as the attack vector is strictly local, but local authentication and execution privileges are necessary to spawn the interacting processes."
}