VulnerabilityPublished 26 Oct 2026Updated 27 Oct 2026

CVE-2026-98986: Linux kernel · namespace: remove the fsnotify marks of a mount namespace in process context

Affects Linux kernelSource GCVE Database

Authoritative record:CVE-2026-98986· Medium

Not known to be exploited.

Data as of 28 Oct 2026, 01:29 UTC

Severity

Medium

Rated by Threat Radar · CVSS not yet scored by NVD

Exploitation evidence

Disclosed: evidence found.
CVE published 23 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Affected software

Product	Affected	Fixed in
Ubuntu 26.10linux`pkg:deb/ubuntu/linux?arch=source&distro=stonking`Other threats	Affected 7.0.0-14.14 – 7.3.0-9.9 6 affected builds	Fixed in–
Ubuntu 26.10linux-aws`pkg:deb/ubuntu/linux-aws?arch=source&distro=stonking`Other threats	Affected 7.0.0-1004.4 – 7.3.0-1003.3 5 affected builds	Fixed in–
Ubuntu 26.10linux-azure`pkg:deb/ubuntu/linux-azure?arch=source&distro=stonking`Other threats	Affected 7.0.0-1004.4 – 7.3.0-1003.3 5 affected builds	Fixed in–
Ubuntu 26.10linux-azure-fde`pkg:deb/ubuntu/linux-azure-fde?arch=source&distro=stonking`Other threats	Affected =7.0.0-1004.4 =7.3.0-1002.3 =7.3.0-1003.4	Fixed in–
Ubuntu 26.10linux-gcp`pkg:deb/ubuntu/linux-gcp?arch=source&distro=stonking`Other threats	Affected 7.0.0-1003.3 – 7.3.0-1003.3 5 affected builds	Fixed in–
Ubuntu 26.10linux-oracle`pkg:deb/ubuntu/linux-oracle?arch=source&distro=stonking`Other threats	Affected 7.0.0-1003.3 – 7.3.0-1003.3 5 affected builds	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

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.

References

Community reviews

Loading reviews…