CVE-2026-98989None▾ SunlitIn 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 o…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac < a0ba48256f5dff6f75a45f8ce39fe57f21df1022Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac < 37a82f400efa4d263542a5fa41755b21057f1e5dLinux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac < c640a01a78e42302879006ed7b7d5a9a943ba815Linux 3.19Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-98987Nonenamespace: look at the topmost mount for a mount namespace file
CVE-2026-99001Nonedrm/xe/i2c: cancel the client work on remove
CVE-2026-98988Nonenamespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
CVE-2026-98992Nonenamespace: don't copy an unmounted mount tree
CVE-2026-98991Nonenamespace: queue a mount only once for mount notifications
CVE-2026-98990Nonenamespace: check a submount for references right before unmounting it