Live › vulnerability › CVE-2026-98987
Go to dashboardWhen a mount namespace file is the topmost mount during move_mount with shared or slave propagation, the kernel can attach an existing mount below the nsfs root instead of where it belongs. The result is that a mount is hidden or stuck and cannot be unmounted synchronously, which the sources describe as a correctness flaw rather than a confirmed privilege escalation.
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 this fix that use shared or slave mount propagation together with bind mounts of mount namespace files, such as container runtimes or namespace-heavy sandboxes. Hosts that do not use mount namespace file bind mounts or propagated mount trees are unlikely to be affected.
No product ranges from the sources yet.
uname -r and compare against the kernel version that carries the upstream fix (unknown from the sources)findmnt -o TARGET,PROPAGATION,FSTYPE)Each 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: look at the topmost mount for a mount namespace file
attach_recursive_mnt() preallocates a mountpoint for the root of the topmost mount of the source so that a mount that already sits at the destination can be put on top of the source or on top of one of its propagated copies.
The copies are made without CL_COPY_MNT_NS_FILE so their chain of overmounts is shorter than the source's. It ends below the first bind mount of a mount namespace file. So while the loop walks up the chain of the source it remembers the mountpoint of that mount in "shorter" and the existing mount is put there for the copies.
But the loop ends at the topmost mount without ever looking at it. If the topmost mount is the only mount namespace file in the chain "shorter" stays NULL and mnt_change_mountpoint() attaches the existing mount of the copy below the root of the mount namespace file. That's a dentry of nsfs. No path walk in the copy's mount namespace ever gets there. The mount is gone until its parent goes and the copy that took its place can't be unmounted synchronously because it has a child:
S bind mount of a file N bind mount of a mount namespace file on top of S A shared mount, B a slave of A, Q mounted on B/file
move_mount(S, A/file) cat B/file -> the content of S instead of Q umount B/file -> EBUSY
Look at every mount of the chain including the topmost one.
This page as .md · .json · in your agent: get_signal("CVE-2026-98987")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.