---
id: "CVE-2026-98989"
kind: "vulnerability"
aliases: ["CVE-2026-98989"]
title: "Linux kernel: recursive bind mount of namespace files leaks memory"
severity: "unknown"
cvss: null
epss: 0.00206
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["containers", "infrastructure", "kernel", "linux", "self-hosted"]
not_affected_if: ["patched-kernel"]
published_at: "2026-10-23T13:17:20+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98989", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98989", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: recursive bind mount of namespace files leaks memory

A recursive bind mount of a mount namespace file taken from another mount namespace can create a mount namespace loop in the Linux kernel. Repeating the operation leaks kernel memory without limit, which a local process can use to exhaust the machine's memory.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the kernel version that carries the fix, which the sources do not name: unknown
- Check whether unprivileged user namespaces are enabled with `sysctl kernel.unprivileged_userns_clone` or `sysctl user.max_user_namespaces`: unknown

## Fix

- Update the Linux kernel to a release that includes the upstream commit titled 'namespace: check a recursive bind mount for mount namespace loops'; the fixed version numbers are unknown from the sources
- Until patched, restrict who can run untrusted code on the host: unknown

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98989
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98989

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_