Look up another CVE · open CVE-2026-97971 in the interactive tracker
CVE-2026-97971
nstree: check listing permission before taking a namespace reference
Published 2026-09-25 (24 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-97971 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.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
legitimize_ns() takes a reference on the candidate namespace before may_list_ns() has decided whether the caller may see it. The __free(ns_put) cleanup on the denied path can drop the last reference to a mount namespace while we still hold the rcu read lock, and put_mnt_ns() may sleep there. This is the same problem commit 2ec2aff3c8e2 ("ns: make sure reference are dropped outside of rcu lock") fixed for the put_user() path. Neither ns_requested() nor may_list_ns() needs a reference, both only look at the namespace type and at the caller's own namespaces, so do the checks first and take the reference last. Splat: Voluntary context switch within RCU read-side critical section! WARNING: kernel/rcu/tree_plugin.h:332 at rcu_note_context_switch+0x238/0x2a0, CPU#5: a/3442 CPU: 5 UID: 1000 PID: 3442 Comm: a Not tainted 7.0.0-30-generic #30-Ubuntu PREEMPT(lazy) RIP: 0010:rcu_note_context_switch+0x238/0x2a0 Call Trace: <TASK> __schedule+0xcf/0x650 schedule+0x27/0x90 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x550/0xaf0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 exp_funnel_lock+0xb2/0x260 synchronize_rcu_expedited+0xe7/0x220 namespace_unlock+0x26a/0x320 put_mnt_ns+0xd3/0x120 mntns_put+0xe/0x20 do_listns+0x13e/0x560 __do_sys_listns+0x126/0x2d0 __x64_sys_listns+0x20/0x30 x64_sys_call+0x2366/0x2390 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
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/nstree.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 with an answer below compiles the affected file into the kernels it ships. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidy
- ?
- not established - no Makefile entry for the affected file
- y
- built into the kernel image on every flavour - only a patch removes it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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-25 (24 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.12%, higher than 1.7% 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.19 | 7.2.7 | 9e673bf5d88a |
| 6.19 | 7.3 | 56ea4e86832d |
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
- The bug is reached only through the local listns() syscall (SYSCALL_DEFINE4(listns) -> do_listns()/do_listns_userns() -> legitimize_ns()). No remote protocol supplies any input.
- AC:LAttack complexity, low
- The attacker controls both sides of the race. One process loops listns() while another creates and tears down its own mount namespaces with unshare(CLONE_NEWUSER|CLONE_NEWNS), so legitimize_ns() ends up holding the last reference on the may_list_ns() denied path.
- PR:LPrivileges required, low
- listns() has no capability gate, and may_list_ns() only filters what is returned after the reference is taken. The commit's splat shows the trigger from UID 1000, and the victim mount namespaces can be created without privilege through user namespaces.
- UI:NUser interaction, none
- The attacker's own syscalls produce both the listing and the namespace teardown. No other user takes part.
- S:UScope, unchanged
- This is corruption and a hang inside the kernel's own namespace and RCU handling. No hypervisor, IOMMU or other separately governed boundary is crossed.
- C:HConfidentiality impact, high
- put_mnt_ns() queues call_rcu(mnt_ns_release_rcu) and then sleeps in synchronize_rcu_expedited() inside do_listns()'s rcu_read_lock. On non-preemptible-RCU kernels that lets the mnt_namespace be kfree'd, and next_ns_common(ns) then walks list pointers read from freed memory.
- I:HIntegrity impact, high
- After the use-after-free, the iterator hands a freed, reallocatable object to legitimize_ns(), which increments its refcount through ns_get_unless_inactive() and calls ns->ops->put(). That gives a write primitive and an indirect call through attacker-sprayable memory.
- A:HAvailability impact, high
- On PREEMPT_RCU kernels, synchronize_rcu_expedited() called from within the caller's own RCU read-side section waits on itself and hangs the task. Elsewhere the result is a sleeping-in-atomic BUG or a use-after-free crash, and an unprivileged user can repeat it at will.