Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-98989

namespace: check a recursive bind mount for mount namespace loops

Products / packages Linux

Published

Share

Severity and exploitation

Not in CISA KEVNo CVSS score

KEV coverage does not rule out exploitation.

KEV checked 14/11/2026, 21:10:34 UTC

Severity

unknown

CVSS measures technical severity, not the likelihood of an attack.

Known exploitation

Not listed in the checked CISA KEV catalog

Absence from CISA KEV does not rule out attacks.

Public exploit

Not established by this record

Missing evidence does not mean no public exploit exists.

Remediation

Fix status not established

No structured fix or guidance is available here. Check the latest publisher advisory.

What this means

In the Linux kernel, the following vulnerability has been resolved:

Source excerpt · Linux

Attack conditions

No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.

Review supporting sources →

Affected versions

Check the exact model, release, and any platform requirements against your installation.

Linux · Linux

Linux

4 ranges

Compare with this publisher’s ranges. This does not inspect your installation.

affected

e149ed2b805fefdccf7ccdfc19eca22fdd4514ac → before b82f3c1131456537a514595c3991b62652507c9d

git versions

e149ed2b805fefdccf7ccdfc19eca22fdd4514ac → before a0ba48256f5dff6f75a45f8ce39fe57f21df1022

git versions

e149ed2b805fefdccf7ccdfc19eca22fdd4514ac → before 37a82f400efa4d263542a5fa41755b21057f1e5d

git versions

e149ed2b805fefdccf7ccdfc19eca22fdd4514ac → before c640a01a78e42302879006ed7b7d5a9a943ba815

git versions

unaffected

unknown

Other versions: unaffected

Linux · Linux

Linux

6 ranges

Compare with this publisher’s ranges. This does not inspect your installation.

affected

3.19

unaffected

0 → before 3.19

semver versions

6.12.117 → through 6.12.*

semver versions

6.18.57 → through 6.18.*

semver versions

7.2.11 → through 7.2.*

semver versions

7.3 → through *

original_commit_for_fix versions

unknown

Other versions: affected

Automatic dependency matching is unavailable for this record. Use the product evidence and publisher’s instructions to check your installation.

What to do

Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.

No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.

cve.new guidance unless attributed to a publisher. This page does not inspect your installation.

Public exploit evidence

No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.

Original source description

Read the full publisher 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

4 sources

Inside the record

Evidence available

Package identity · not supplied
Version evidence
Remediation guidance · not supplied
Weakness classification · not supplied
Additional publishers · not supplied

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-98989

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Environment requirements

These conditions apply together as specified by the publisher. A matching product name alone does not establish exposure.

Linux · platform conditions

Any condition may hold

Vulnerable product

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

From (inclusive): 3.19

Before: 6.12.117

Vulnerable product

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

From (inclusive): 3.19

Before: 6.18.57

Vulnerable product

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

From (inclusive): 3.19

Before: 7.2.11

Vulnerable product

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

From (inclusive): 3.19

Before: 7.3

Applicability preview
[
  {
    "nodes": [
      {
        "operator": "OR",
        "negate": false,
        "cpeMatch": [
          {
            "vulnerable": true,
            "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
            "versionStartIncluding": "3.19",
            "versionEndExcluding": "6.12.117"
          },
          {
            "vulnerable": true,
            "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
            "versionStartIncluding": "3.19",
            "versionEndExcluding": "6.18.57"
          },
          {
            "vulnerable": true,
            "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
            "versionStartIncluding": "3.19",
            "versionEndExcluding": "7.2.11"
          },
          {
            "vulnerable": true,
            "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
            "versionStartIncluding": "3.19",
            "versionEndExcluding": "7.3"
          }
        ]
      }
    ]
  }
]
Contributing organizations · 1
Linux

Assigning organization

2026-11-10

Timeline

All times UTC
  1. Advisory published

    Publication date supplied by the source.

  2. Source updated

    Latest modification date supplied by the source.

  3. Last imported by cve.new

    Latest catalog import, not the date we first saw this advisory.

What changed

Follow changes
No substantive changes have been recorded here yet. History starts when cve.new observes a change after tracking is enabled; earlier edits are not reconstructed.

Large field values are marked as truncated previews. Original source snapshots remain retained.