CVE-2026-98989

namespace: check a recursive bind mount for mount namespace loops

Published Oct 23, 2026 CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
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.

Analysis

AI-generated

Technical impact

The Linux kernel's namespace subsystem allows recursive bind mounts of namespace files without adequate loop detection. When a mount namespace file is bind‑mounted with the MS_REC flag, the kernel copies all nested namespace files, potentially creating a cycle that is not detected because the check only examines the dentry of the bind mount start. Repeating this action causes the kernel to allocate shared memory for each new namespace instance, increasing resource usage until the system runs out of shared memory, leading to a denial‑of‑service. The CWE identifier CWE‑772 indicates a circular resource usage issue.

Affected Systems

All Linux kernel implementations that have not incorporated the patch fixing the do_loopback() loop check are affected. No specific version ranges are provided in the data, so kernel administrators should consider any unpatched kernel version vulnerable.

Risk and Exploitability

Based on the description, it is inferred that the attack vector requires local execution privileges, typically root or processes with CAP_SYS_ADMIN, to issue bind mounts. The vulnerability is not listed in the CISA KEV catalog and has an EPSS score of <1%, indicating a low probability of exploitation. The CVSS score of 5.5 reflects moderate severity. If an attacker can perform recursive bind mounts on nsfs or pidfs files, the kernel will allocate shared memory for each new namespace, and an attacker can trigger resource exhaustion. Even though the exploit likelihood is low, the potential for system instability and denial of service remains a concern in privileged environments.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply kernel updates that include the do_loopback() loop‑check fix; the latest stable releases incorporate this patch.
  • If updating is not immediately possible, configure SELinux or AppArmor policies to prohibit recursive MS_REC bind mounts on nsfs or pidfs files, thereby preventing the creation of namespace bind‑mount loops.
  • Limit shared memory resources by adjusting kernel limits (e.g., /proc/sys/kernel/shmall, /proc/sys/kernel/shmmax) or cgroup memory quotas to reduce the impact of any accidental namespace leaks.
  • Monitor shared memory usage and system status for abnormal growth, and investigate any sudden increases promptly.

Generated by OpenCVE AI on October 29, 2026 at 21:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-9018-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9018-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
History
Type Values Removed Values Added
Weaknesses CWE-770
Type Values Removed Values Added
Weaknesses CWE-772
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux
Type Values Removed Values Added
Weaknesses CWE-770
Type Values Removed Values Added
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.
Title namespace: check a recursive bind mount for mount namespace loops
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses
  • CWE-772

    Missing Release of Resource after Effective Lifetime

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Nov 10, 2026, 6:15 PM
Reserved
Sep 25, 2026, 10:25 AM
Status
Received
Published
Oct 23, 2026, 1:17 PM
Modified
Nov 10, 2026, 7:22 PM
Severity
Moderate
Public date
Oct 23, 2026, 12:00 AM