Cloudanix VulnDB

CVE-2026-98986

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can crash the whole system when certain file-monitoring features are used with isolated file-system views, so administrators should install the latest kernel updates right away.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability causes fsnotify marks on a mount namespace to be deleted from RCU softirq context via mnt_ns_release_rcu, triggering mutex acquisition inside fsnotify_destroy_marks while in_atomic, violating process-context-only locking rules for fanotify FAN_MARK_MNTNS marks.

Why it matters to the business

Linux systems using fanotify on mount namespaces may experience kernel crashes or lockdep warnings during namespace teardown, leading to service disruption and forced reboots; the issue affects recent kernels and requires urgent patching due to its recency.

How an attack unfolds

An attacker with root in a user namespace creates a fanotify group with a FAN_MARK_MNTNS mark on another task's mount namespace, allows the marked task to exit so the namespace is freed via call_rcu, and the subsequent RCU callback attempts mutex operations from softirq context, hitting the sleeping-function bug.

How to fix it

Apply the upstream fix that moves fsnotify mark removal into free_mnt_ns before handing the namespace to RCU; rebuild and deploy updated kernels across all affected Linux distributions as soon as vendor packages are available.

How to confirm the fix worked

Confirm the presence of the commit that relocates mark deletion to free_mnt_ns, verify no sleeping-function or lockdep warnings appear when exercising fanotify mount-namespace marks, and check kernel build logs for the corrected mnt_ns_release path.

Typical attack path

  1. Obtain root inside a user namespace
  2. Create fanotify group and attach FAN_MARK_MNTNS mark to a target mount namespace
  3. Cause the owning task to exit, triggering namespace release
  4. RCU softirq invokes mnt_ns_release_rcu and attempts fsnotify_destroy_marks under mutex
  5. Kernel hits BUG or lockdep warning and may panic

How to detect it

Search kernel logs and crash dumps for the exact BUG message about sleeping function called from invalid context at mutex.c together with the fsnotify_destroy_marks and mnt_ns_release_rcu stack frames; also look for fanotify-related namespace teardown events preceding the crash.

  • BUG: sleeping function called from invalid context at kernel/locking/mutex.c
  • fsnotify_destroy_marks
  • mnt_ns_release_rcu
  • rcu_core
  • FAN_MARK_MNTNS

What your security team should do

  • Immediately schedule kernel updates for all production Linux hosts within the CISA-style remediation window
  • Audit workloads that use fanotify with mount namespaces and restrict such usage where possible
  • Enable kernel lockdep and sleeping-while-atomic debugging on test systems to validate the fix
  • Monitor for vendor kernel advisories and backports for LTS branches

The record

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.

Affected packages

Ecosystem Package Introduced Fixed