CVE-2026-98986 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
namespace: remove the fsnotify marks of a mount namespace in process context
mnt_ns_release() drops the last passive reference of a mount namespace and removes its fanotify marks via fsnotify_mntns_delete(). That takes the mutex of every group with a mark on the namespace and the spinlock of the connector. Fine from process context. But mnt_ns_tree_remove() hands the reference the namespace was allocated with to call_rcu() and so the marks are removed from the RCU softirq:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:623 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/3 __mutex_lock+0x113/0x24b0 fsnotify_destroy_marks+0x11b/0x3d0 mnt_ns_release_rcu+0x57/0xa0 rcu_core+0x6b6/0x1e40
and lockdep complains about the connector lock being taken from softirq context. A fanotify group with a FAN_MARK_MNTNS mark on the mount namespace of another task is all that's needed. Root in a user namespace can do that for a mount namespace it owns. The task exits and the namespace is freed with the mark still on it.
Remove the marks in free_mnt_ns() before the namespace is handed to RCU. That runs in process context once the last active reference is gone. A mark is added through a file descriptor to the namespace which holds an active reference so no mark can show up after that.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel vulnerability described involves a critical concurrency and locking violation within the mount namespace cleanup logic, specifically affecting how fanotify marks are handled during namespace deallocation. The core issue stems from a mismatch between the execution context required for certain synchronization primitives and the actual context in which they were being invoked. When a process exits or releases its final reference to a mount namespace, the kernel invokes mnt_ns_release() to clean up associated resources. This function originally delegated the removal of fanotify marks to fsnotify_mntns_delete(), which operates correctly when called from process context because it acquires mutexes and spinlocks that are safe in such environments. However, due to reference counting mechanics involving call_rcu(), the actual cleanup work was deferred to an RCU callback executed in softirq context via mnt_ns_release_rcu(). This shift in execution context triggered a kernel bug where sleeping functions like mutex locks were called from atomic contexts where they are strictly prohibited, leading to potential system instability or crashes.
From a technical perspective, this flaw represents a classic case of improper synchronization primitive usage across different execution domains. The Linux kernel enforces strict rules regarding which locking mechanisms can be used in process context versus interrupt or softirq context. Mutexes require the ability to sleep and schedule other tasks, making them incompatible with atomic contexts where preemption is disabled. By attempting to acquire a mutex within an RCU callback running as part of the scheduler's softirq processing, the kernel violated these fundamental constraints. This resulted in the BUG message indicating that a sleeping function was called from an invalid context, along lockdep warnings regarding connector locks being taken improperly. The vulnerability can be triggered by any user with root privileges inside a user namespace who creates fanotify marks on mount namespaces belonging to other tasks and then causes those tasks to exit, thereby initiating the problematic cleanup sequence.
The operational impact of this vulnerability includes kernel panics or oopses that disrupt system stability, particularly under conditions where multiple processes interact with mount namespaces while maintaining active fanotify subscriptions. Since the issue arises during namespace teardown, it affects systems heavily utilizing containerization technologies like Docker or Kubernetes, which frequently create and destroy mount namespaces for isolation purposes. An attacker exploiting this flaw could potentially cause a denial of service by triggering repeated kernel crashes through crafted sequences of process exits involving specific filesystem notification setups. While direct code execution is unlikely due to the nature of the fault being a locking violation rather than memory corruption, the resulting instability poses significant risks to production environments relying on consistent system uptime and predictable behavior under load.
Mitigation strategies primarily involve applying upstream kernel patches that restructure the cleanup logic to ensure all operations requiring mutexes are performed in process context before transitioning resources to RCU protection. The fix involves moving the removal of fanotify marks into free_mnt_ns(), which executes while still holding active references and thus remains within safe execution boundaries. This ensures that synchronization primitives are used correctly according to their design constraints. Administrators should apply kernel updates provided by their distribution vendors as soon as available, ensuring that all systems utilizing containerized workloads or advanced filesystem notification features remain patched against this concurrency flaw. Regular auditing of fanotify configurations and monitoring for unusual patterns in namespace lifecycle events can also help detect potential exploitation attempts before they trigger critical failures.
This vulnerability aligns with CWE-674, which covers uncontrolled recursion and resource consumption issues arising from improper handling of system resources during cleanup phases. It also relates to ATT&CK technique T1053, specifically the Scheduled Task or Job subcategory if an attacker were attempting to automate repeated triggering for denial-of-service purposes, although more accurately it reflects internal kernel logic errors rather than external attack techniques per se. The resolution emphasizes the importance of maintaining strict separation between atomic and process contexts in low-level system programming, ensuring that reference counting mechanisms do not inadvertently shift execution environments into unsafe states where standard synchronization tools cannot function correctly.