CVE-2026-97903: exit: hold a reference to thread_pid across proc_flush_pid

In the Linux kernel, the following vulnerability has been resolved:

exit: hold a reference to threadpid across procflushpid

Commit 0a36bad01731 ("releasetask: kill the no longer needed get/putpid(threadpid)") removed the reference around procflushpid(). It assumed that freepids(post.pids) at the end of releasetask() would keep threadpid alive until then.

That assumption is wrong. changepid() only records a detached PID in post.pids when pidhastask() is false for every PIDTYPE. If another task still uses the exiting task's PID as its process group or session ID, unhashprocess() removes the exiting task's PIDTYPEPID link but leaves the PID out of post.pids. releasetask() therefore holds no reference to it after dropping tasklistlock.

The other task can then remove the remaining PIDTYPE links. Its freepids() call schedules delayedputpid(), and the RCU callback can free the PID before the first releasetask() reaches procflushpid().

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 procinvalidatesiblingsdcache+0x3e2/0x3f0 Read of size 8 by task h7pidreaper/1921

Call Trace: procinvalidatesiblingsdcache releasetask waitconsidertask dowait dowait kernelwait4

Freed by task 0: kmemcachefree putpid delayedputpid rcucore

Last potentially related work creation: callrcucommon freepids ksyssetsid

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 procflushpid() was protected, and the balancing putpid() performed the final free afterward.

Take a reference before unhashprocess() clears p->threadpid and release it after procflushpid() 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.