CVE-2026-99218 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
coredump: hold RCU while releasing parked threads
coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu.
But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away.
So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory.
Hold rcu across the loop.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel vulnerability identified involves a race condition within the core dump subsystem, specifically during the process of releasing parked threads after a coredump operation has completed. The function coredump_finish is responsible for cleaning up these auxiliary threads by clearing their task pointers and invoking wake_up_process to signal them that they can terminate or proceed with normal execution. However, this sequence was executed without holding an RCU read-side lock and without maintaining a reference count on the target tasks. This omission creates a critical window where the kernel assumes the thread structures remain valid in memory, while in reality, those threads may have already exited due to preemption or spurious wakeups unrelated to the coredump logic.
The technical flaw stems from the asynchronous nature of task lifecycle management within the Linux scheduler and memory subsystems. When a parked thread is signaled via wake_up_process, it does not necessarily need that specific wakeup event to exit; external factors such as signal delivery, process group termination, or simple preemption can cause the task structure to be freed immediately after its pointer is cleared but before the wakeup call completes. If the coredump client thread is preempted between clearing the task pointer and calling wake_up_process, the target thread may fully terminate and have its memory reclaimed by the slab allocator. Subsequently, when try_to_wake_up attempts to access this now-freed memory region to acquire the pi_lock for priority inheritance handling, it results in a use-after-free condition. This can lead to kernel panics, data corruption, or potentially arbitrary code execution if an attacker can influence the allocation of new objects into that freed memory space.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as the core issue is accessing memory after it has been made available for reallocation without proper synchronization primitives to ensure structural integrity. In terms of adversarial tactics, this scenario relates to ATT&CK technique T1059, Command and Scripting Interpreter, if exploited in conjunction with other vulnerabilities to gain initial access, but more directly maps to privilege escalation vectors where kernel memory corruption allows bypassing security boundaries. The lack of RCU protection means that the code fails to adhere to standard kernel concurrency practices which mandate holding read-side locks when dereferencing pointers that may be concurrently freed by write-side critical sections elsewhere in the subsystem.
The operational impact of this flaw is severe, as it compromises system stability and potentially confidentiality or integrity depending on exploitation success. A local attacker with sufficient privileges to trigger a coredump could induce a denial of service through kernel oops or panic. In more sophisticated scenarios, careful timing attacks combined with heap spraying techniques might allow the overwriting of critical kernel data structures, leading to privilege escalation from user space to root level. The vulnerability affects systems where core dumps are enabled and triggered under conditions that maximize thread scheduling variability, such as high-load environments or specific debugging configurations.
Mitigation strategies primarily involve applying vendor-provided kernel patches that implement RCU read-side locking around the loop in coredump_finish. This ensures that any task structure referenced during the wakeup sequence remains valid until the operation completes. Administrators should ensure their systems are updated with the latest stable kernel versions containing this fix. Additionally, disabling core dumps for unprivileged users or restricting them to specific directories can reduce the attack surface by limiting opportunities for triggering the vulnerable code path. Monitoring system logs for unexpected coredump events and ensuring strict resource limits on process creation can further mitigate potential exploitation attempts while patching is applied.