Description

In the Linux kernel, the following vulnerability has been resolved: nstree: check listing permission before taking a namespace reference 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>

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:24.980Z",
  "pubdate": "2026-09-25T11:17:24.980Z",
  "executiveSummary": "The vulnerability involves a race condition and improper reference counting within the Linux kernel's namespace management subsystem during the listns system call.\nThe vulnerability is classified as an improper synchronization error leading to a sleep-while-atomic violation. It occurs when a kernel thread triggers a reference drop within an RCU read-side critical section.\nAffected systems include Linux kernel versions where the listns system call logic improperly orders security permission checks relative to resource acquisition.\nAn unprivileged local attacker could potentially exploit this behavior to trigger a kernel panic or instability, leading to a denial-of-service condition.\nExploitation requires local access to the system and the ability to execute the listns system call to trigger the race condition between namespace validation and reference cleanup.\nThe risk is primarily tied to system availability, as the triggered kernel fault forces a voluntary context switch while interrupts or preemption are restricted, violating RCU constraints.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper sequence of operations within the legitimize_ns() function. Specifically, the kernel acquires a reference to a candidate namespace before verifying if the calling process has the necessary permissions to list or inspect that namespace via the may_list_ns() check.\nIn the vulnerable implementation, the __free(ns_put) cleanup mechanism is invoked if the permission check fails. If this occurs while the process holds an RCU (Read-Copy-Update) read lock, the subsequent call to put_mnt_ns() may attempt to sleep if it drops the final reference to a mount namespace. This violates RCU read-side critical section requirements, which strictly prohibit sleeping or context switching.\nThe attack flow proceeds as follows: 1) A local process invokes the listns system call. 2) The kernel calls legitimize_ns(), which proceeds to increment the reference count on a namespace candidate. 3) The kernel then executes may_list_ns() to determine if access is permitted. 4) If access is denied, the cleanup path triggers put_mnt_ns(). 5) Because this entire sequence is wrapped in an RCU read-side lock, the call to put_mnt_ns() attempts a mutex operation (e.g., namespace_unlock), resulting in a voluntary context switch. 6) The kernel's RCU subsystem detects this illegal schedule while in an atomic context and triggers a kernel warning (splat) or a panic.\nThe vulnerable component is the namespace lookup and validation logic within the kernel's namespace infrastructure, specifically affecting the interaction between reference acquisition and security authorization.\nThe issue is exacerbated by the fact that neither ns_requested() nor may_list_ns() requires a reference to the namespace to perform their checks; they only require access to the namespace type and the caller's own namespace structures. By failing to perform these lightweight checks first, the kernel unnecessarily holds an active reference, forcing a potentially dangerous cleanup path during an access denial.\nThis vulnerability highlights a design flaw in the management of reference lifetimes within the RCU-protected scope of the listns system call. By reordering these operations—performing permission checks before reference acquisition—the necessity of a complex, sleep-prone cleanup path while holding an RCU lock is eliminated, thereby preventing the illegal kernel context switch."
}