Linux Kernel CVE-2026-97903

Requires local, unprivileged code execution on an affected Linux kernel (6.16 through the fixed 6.18.53/7.2.7 range, plus the 0a36bad01731 regression window). Triggering requires winning a narrow scheduler/RCU race: the attacker must have wait4(-1) reap an exiting task at the same instant another task (via setsid()/free_pids) drops the final PIDTYPE link, so that delayed_put_pid's RCU callback frees struct pid before the first release_task() reaches proc_flush_pid(). The exiting task's PID must still be in use as another task's process-group or session ID (the condition that keeps it out of post.pids). Limiting factors: no remote vector (AV:L), no network exposure, requires valid local account (PR:L), success is timing-dependent, and the outcome is a crash - no controlled memory read/write or privilege gain is available.

This is a niche, crash-dominant memory-safety bug being scored far above its real-world impact. The NVD CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H = 7.8 'High') asserts full confidentiality/integrity/availability compromise, but the vulnerability description EXPLICITLY contradicts this: 'No controlled read or write, information leak, or privilege escalation is claimed.' The observed effect is a KASAN slab-use-after-free (read of freed pid->inodes in proc_invalidate_siblings_dcache) that manifests as a kernel crash - i.e. denial of service, not a controlled primitive. I therefore treat C:H/I:H as unsupported; realistic impact is A:H (crash) with at most I:L (uncontrolled corruption). The AC:L rating is also generous: this is an RCU/timing race requiring wait4(-1) to be raced against setsid() at exactly the window between __unhash_process() and proc_flush_pid(), which is timing-dependent (AC:H is more defensible, though the reproducer hit it 3/3 boots). Positive signals for exploitation are absent: no EPSS score, no CISA KEV listing, and no public exploit - a working reproducer is only 'available privately on request.' Bottom line: real priority is LOW-to-MEDIUM local DoS, not the High/privesc the tag and CVSS imply. Patch it via normal kernel update cadence; it is not an emergency.

An unprivileged local user runs a program that repeatedly forks children and races wait4(-1) reaping against another task calling setsid() (so the exiting task's PID is still held as a process-group/session ID and is dropped by another task's free_pids/RCU callback). Won the race, proc_flush_pid() dereferences the already-freed struct pid, producing a slab-use-after-free that crashes the kernel. Only a private reproducer exists - no public PoC or evidence of exploitation, and no controlled read/write is claimed.