Live › vulnerability › CVE-2026-98986
Go to dashboardWhen a mount namespace is freed, the kernel removes fanotify marks from it inside an RCU softirq, where sleeping locks are not allowed, which triggers a sleeping-in-atomic-context bug and lockdep warnings. A local user who can create a user namespace and a fanotify group with a FAN_MARK_MNTNS mark can trigger the bug, and the sources do not describe the full impact beyond that.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with this fix not yet applied; the sources do not name affected kernel versions or a patched version. Root in a user namespace it owns is needed to set up the mark, so multi-tenant hosts and container hosts allowing unprivileged user namespaces are the systems to look at first.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98986")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.