Cloudanix VulnDB

CVE-2026-98989

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux's handling of certain file-system mount operations can let attackers gradually consume system memory until the machine becomes unusable.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw bypasses cycle-detection checks in do_loopback() for recursive (MS_REC) bind mounts of nsfs/mnt files from foreign mount namespaces, allowing creation of self-referential mount stacks that leak entire mount namespaces and their associated kernel objects.

Why it matters to the business

Unprivileged or containerized workloads can trigger unbounded kernel memory consumption (primarily Shmem) leading to host-level resource exhaustion and denial of service.

How an attack unfolds

An attacker running inside an older mount namespace obtains file descriptors for mount-namespace or pid-namespace files, then repeatedly issues mount(..., MS_BIND|MS_REC) operations; may_copy_tree() accepts the nsfs targets regardless of ancestry, so the kernel copies the descriptors and leaks the referenced namespaces.

How to fix it

Apply the upstream kernel commit that adds the recursive-mount namespace-loop check inside do_loopback() before grafting the copied tree; rebuild and deploy the patched kernel on all affected hosts.

How to confirm the fix worked

Confirm the presence of the new ancestry check in the do_loopback() path for CL_COPY_MNT_NS_FILE operations and verify that attempts to create cross-namespace recursive bind-mount stacks now fail with the expected error.

Typical attack path

  1. Run a process inside a mount namespace older than the target
  2. Open file descriptors to /proc/<pid>/ns/mnt or equivalent nsfs entries
  3. Issue recursive bind-mount of those descriptors onto a writable location
  4. Repeat the operation to create arbitrarily deep stacks and exhaust memory

How to detect it

Inspect audit logs or strace output for processes issuing mount syscalls containing MS_BIND|MS_REC against nsfs or mntfs targets; correlate with rapid unexplained growth in Shmem or kmemleak reports referencing mount namespaces.

  • MS_BIND|MS_REC
  • mount.*nsfs
  • mount.*mnt:
  • Shmem:.*kB
  • do_loopback

What your security team should do

  • Prioritize kernel updates on any system allowing unprivileged mounts or running containers
  • Where feasible, restrict unprivileged users from performing bind mounts via mount namespaces or user namespaces
  • Monitor Shmem and slab usage for sudden spikes originating from mount-related workloads

The record

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.

Affected packages

Ecosystem Package Introduced Fixed