CVE-2026-98986: namespace: remove the fsnotify marks of a mount namespace in process context
In the Linux kernel, the following vulnerability has been resolved:
namespace: remove the fsnotify marks of a mount namespace in process context
mntnsrelease() drops the last passive reference of a mount namespace and removes its fanotify marks via fsnotifymntnsdelete(). That takes the mutex of every group with a mark on the namespace and the spinlock of the connector. Fine from process context. But mntnstreeremove() hands the reference the namespace was allocated with to callrcu() and so the marks are removed from the RCU softirq:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:623 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 0, name: swapper/3 mutexlock+0x113/0x24b0 fsnotifydestroymarks+0x11b/0x3d0 mntnsreleasercu+0x57/0xa0 rcucore+0x6b6/0x1e40
and lockdep complains about the connector lock being taken from softirq context. A fanotify group with a FANMARKMNTNS 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 freemntns() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Remove the fsnotify/fanotify marks of a mount namespace in free_mnt_ns() before handing the namespace to RCU, so mark removal occurs in process context rather than from the RCU softirq.