coredump: hold RCU while releasing parked threads
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. The coredump client is preempted between clearing the thread's task entry and calling wake_up_process() on it.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 37/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel is affected, specifically its core dump handling code, which releases threads parked during a process coredump. The flaw could let a thread be freed while the kernel still tries to wake it, potentially causing memory corruption or a crash.
Read the original description
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.
What to do
Check whether your setup matches what the bug needs.
The coredump client is preempted between clearing the thread's task entry and calling wake_up_process() on it.Workaround: The checked facts give no workaround. Until a fixed kernel is installed, no mitigation is recorded in these facts.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
2.6.27
Evidence 6
- Link
- Link
- Link
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-99218
What does this mean?
A thread that has exited and been freed can still be woken up by the coredump code. The wake-up path then takes a lock in memory that has already been freed, which is a use-after-free. This happens when the coredump client is preempted between clearing the thread's task entry and calling wake_up_process() on it.Source: git.kernel.org
Am I affected, and how do I check?
The checked facts name Linux but list no version ranges, so the affected kernel versions are not stated. The bug needs the coredump client to be preempted in that window. To check a system, compare its kernel version from uname -r against the affected versions in the advisory.Source: git.kernel.org
What should I do about it?
The checked facts do not name a fixed version, so no upgrade target is stated. Check the kernel advisory or the stable branch for the release that includes the RCU fix.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
The checked facts give no workaround. Until a fixed kernel is installed, no mitigation is recorded in these facts.Source: git.kernel.org