Look up another CVE · open CVE-2026-80929 in the interactive tracker
CVE-2026-80929
sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[]
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem kernel. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80929 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
cad_pid is global, and kill_cad_pid() is only used in the root namespace. However, due to pid_table_root_permissions(), a non-root user can unshare pid/user namespaces and modify it from the child namespace. This makes no sense and is simply wrong. Move it to kern_reboot_table[] where it logically belongs; this ensures that only GLOBAL_ROOT_UID can read/modify this sysctl. Note that this patch doesn't preserve "#ifdef CONFIG_PROC_SYSCTL" around the "cad_pid"; CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL, so it is always set when kern_reboot_table[] is compiled.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/pid.c
kernel/reboot.c
- What this is
- THE RESTMAINTAINERS section matched on */ · linux-kernel@vger.kernel.org · Buried alive in reporters
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- kernel
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.17 | 6.18.50 | e8527de7fea1 |
| 6.17 | 7.2.4 | a09bc4eaa67e |
| 6.17 | 7.3 | 7170ca01623b |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Unprivileged local processes reach proc_do_cad_pid() by opening and writing /proc/sys/kernel/cad_pid after creating user and PID namespaces; this is a procfs sysctl syscall path, not a network, adjacent-wireless, or physical-device handler.
- AC:LAttack complexity, low
- The attacker fully controls namespace creation and concurrent sysctl reads/writes of the shared global cad_pid pointer, so the proc_do_cad_pid() use-after-free race does not depend on victim state, rare configs, or other conditions outside attacker influence.
- PR:LPrivileges required, low
- pid_table_root_permissions() treats CAP_SYS_ADMIN or uid 0 in the PID namespace's user namespace as owner of the 0600 cad_pid sysctl, which an unprivileged user obtains by unsharing user and PID namespaces rather than needing init-namespace root.
- UI:NUser interaction, none
- The attacker triggers the flaw entirely through their own unshare, proc mount, and read/write of kernel.cad_pid; no other user must press Ctrl-Alt-Del, mount a filesystem, or take any action.
- S:UScope, unchanged
- Successful exploitation corrupts host kernel memory and hijacks the global cad_pid used by kill_cad_pid(); this remains inside the kernel's security authority and is not a VM, IOMMU, or DMA boundary bypass.
- C:HConfidentiality impact, high
- Racing a cad_pid sysctl write (put_pid of the last reference) against a sysctl read use-after-frees struct pid in pid_vnr()/pid_nr_ns(), which per kernel CVSS guidance provides an arbitrary kernel-read primitive via slab reuse.
- I:HIntegrity impact, high
- The same use-after-free of struct pid is exploitable for heap spraying and control-flow hijack of kernel PID/signal paths, and the write also replaces host-global cad_pid so privileged kernel SIGINT/SIGPWR are redirected away from init.
- A:HAvailability impact, high
- The use-after-free produces a kernel oops or panic on the pid_nr_ns() dereference of freed memory, as shown by the KASAN report; replacing cad_pid also persistently breaks host Ctrl-Alt-Del and power-button delivery to init.