Live › vulnerability › CVE-2026-98989
Go to dashboardA 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 written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel without the upstream fix are affected. The flaw needs a local process that can call mount with MS_BIND and MS_REC on a nsfs or pidfs file, so multi-tenant hosts and container platforms deserve the most attention. Single-user machines with no untrusted local code have less exposure.
No product ranges from the sources yet.
uname -r and compare against the kernel version that carries the fix, which the sources do not name: unknownsysctl kernel.unprivileged_userns_clone or sysctl user.max_user_namespaces: unknownEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98989")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.