VulnerabilityPublished 23 Oct 2026

CVE-2026-98989: Linux kernel · namespace: check a recursive bind mount for mount namespace loops

Source GCVE Database

Authoritative record:CVE-2026-98989· Medium

Not known to be exploited · fixed in c640a01a78e42302879006ed7b7d5a9a943ba815 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:47 UTC

Severity

Medium

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS: 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in c640a01a78e42302879006ed7b7d5a9a943ba815, a0ba48256f5dff6f75a45f8ce39fe57f21df1022, 37a82f400efa4d263542a5fa41755b21057f1e5d

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.

ghsa-88xj-3p4j-2c73

What to do

Upgrade Linux kernel to c640a01a78e42302879006ed7b7d5a9a943ba815, a0ba48256f5dff6f75a45f8ce39fe57f21df1022 or 37a82f400efa4d263542a5fa41755b21057f1e5d.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ e149ed2b805fefdccf7ccdfc19eca22fdd4514ac, < c640a01a78e42302879006ed7b7d5a9a943ba815	Fixed in c640a01a78e42302879006ed7b7d5a9a943ba815
LinuxLinux	Affected ≥ e149ed2b805fefdccf7ccdfc19eca22fdd4514ac, < a0ba48256f5dff6f75a45f8ce39fe57f21df1022	Fixed in a0ba48256f5dff6f75a45f8ce39fe57f21df1022
LinuxLinux	Affected ≥ e149ed2b805fefdccf7ccdfc19eca22fdd4514ac, < 37a82f400efa4d263542a5fa41755b21057f1e5d	Fixed in 37a82f400efa4d263542a5fa41755b21057f1e5d
LinuxLinux	Affected =3.19	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc/<pid>/ns/<ns> and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw Mount 152 is a mount of the mount namespace file of mount namespace 4026532293 inside mount namespace 4026532293. That namespace and every mount in it are leaked... All it takes is a process in an older mount namespace that stacks the file and repeating it leaks without limit: after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB do_move_mount() runs check_for_nsfs_mounts() over a detached tree for exactly that reason. Do the same for the copy before it is grafted.

References

Community reviews

Loading reviews…