---
id: "CVE-2026-98986"
kind: "vulnerability"
aliases: ["CVE-2026-98986"]
title: "Linux kernel: fanotify mount-namespace marks removed in unsafe context"
severity: "unknown"
cvss: null
epss: 0.00206
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["containers", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: ["unknown"]
published_at: "2026-10-23T13:17:20+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98986", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98986", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: fanotify mount-namespace marks removed in unsafe context

When 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, check and fix written by a model from the sources; labelled as such._

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98986
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98986

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_