CVE-2026-98986

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.