Description

In the Linux kernel, the following vulnerability has been resolved: exit: hold a reference to thread_pid across proc_flush_pid Commit 0a36bad01731 ("release_task: kill the no longer needed get/put_pid(thread_pid)") removed the reference around proc_flush_pid(). It assumed that free_pids(post.pids) at the end of release_task() would keep thread_pid alive until then. That assumption is wrong. __change_pid() only records a detached PID in post.pids when pid_has_task() is false for every PIDTYPE. If another task still uses the exiting task's PID as its process group or session ID, __unhash_process() removes the exiting task's PIDTYPE_PID link but leaves the PID out of post.pids. release_task() therefore holds no reference to it after dropping tasklist_lock. The other task can then remove the remaining PIDTYPE links. Its free_pids() call schedules delayed_put_pid(), and the RCU callback can free the PID before the first release_task() reaches proc_flush_pid(). An unprivileged reproducer races wait4(-1) against setsid() to trigger this ordering. Three of three fresh v7.2 KASAN boots reported: BUG: KASAN: slab-use-after-free in proc_invalidate_siblings_dcache+0x3e2/0x3f0 Read of size 8 by task h7_pid_reaper/1921 Call Trace: proc_invalidate_siblings_dcache release_task wait_consider_task __do_wait do_wait kernel_wait4 Freed by task 0: kmem_cache_free put_pid delayed_put_pid rcu_core Last potentially related work creation: __call_rcu_common free_pids ksys_setsid KASAN identified a 144-byte object from the pid cache and located the bad read 80 bytes into the freed object, matching pid->inodes. With an explicit reference, three of three fresh boots completed without a KASAN report. The concurrent RCU callback dropped its reference while proc_flush_pid() was protected, and the balancing put_pid() performed the final free afterward. Take a reference before __unhash_process() clears p->thread_pid and release it after proc_flush_pid() completes. A tested source reproducer is available privately on request. No controlled read or write, information leak, or privilege escalation is claimed. The mainline patch applies directly to v6.19.y and newer; v6.16.y through v6.18.y need a context-adjusted backport.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:17.150Z",
  "pubdate": "2026-09-25T11:17:17.150Z",
  "executiveSummary": "This vulnerability is a use-after-free (UAF) flaw residing in the Linux kernel's process management subsystem, specifically within the task release path.\nThe issue arises from an incorrect assumption regarding the lifetime management of the 'thread_pid' structure during the execution of 'release_task'.\nAn unprivileged local attacker can exploit this race condition to trigger a kernel use-after-free, resulting in memory corruption or system instability.\nThe vulnerability affects the kernel's process ID management logic, where a race between 'release_task' and concurrent system calls like 'setsid' allows for premature deallocation of the PID structure via RCU callbacks.\nSuccessful exploitation leads to a 'slab-use-after-free' state, as verified by KASAN reports in 'proc_invalidate_siblings_dcache'.\nWhile currently characterized as a stability issue, use-after-free vulnerabilities in the kernel often possess the potential for local privilege escalation or arbitrary code execution depending on the heap layout and specific object reclamation state.\nExploitation requires the ability to execute local code and orchestrate a precise race condition between task termination and process group/session ID manipulation.",
  "technicalDetails": "The root cause is a deficiency in the reference counting logic for 'thread_pid' within 'release_task'. A previous commit (0a36bad01731) erroneously removed explicit 'get_pid' and 'put_pid' calls, incorrectly assuming that 'free_pids(post.pids)' would maintain the object's longevity until the completion of 'proc_flush_pid'.\nIn the Linux kernel, 'pid' structures are reference-counted. The 'thread_pid' represents the task's primary PID. When a process exits, 'release_task' is responsible for cleanup. The kernel's logic assumes that if a PID is not in 'post.pids', it is still held by other internal structures.\nHowever, 'pid_has_task()' logic is insufficient for complex scenarios where a process's PID is utilized by other tasks as a process group ID or session ID. In such cases, 'unhash_process()' clears the 'PIDTYPE_PID' link but leaves the PID absent from 'post.pids'.\nThe exploitation flow proceeds as follows: 1) A victim task begins exiting, entering 'release_task'. 2) It drops 'tasklist_lock', releasing its handle on the PID. 3) Simultaneously, an attacker process executes 'setsid()' or other calls that manipulate process group/session IDs, causing a separate execution thread to release the remaining PID references. 4) The kernel's RCU callback mechanism ('delayed_put_pid') triggers, freeing the PID memory object via 'kmem_cache_free'. 5) The original 'release_task' execution flow continues, attempting to reference the already-freed 'thread_pid' during the call to 'proc_flush_pid', specifically within 'proc_invalidate_siblings_dcache'.\nThis triggers a 'slab-use-after-free' condition. The KASAN report confirms that the kernel attempts to access the 'pid->inodes' member (offset 80 bytes) of a freed object.\nThe vulnerability is present in versions predating the fix, notably impacting Linux kernel versions through 6.18.y, with variations in backport requirements for versions 6.16.y to 6.18.y."
}