CVE-2026-98984: dcache: don't put a mountpoint on a dentry that's being removed

In the Linux kernel, the following vulnerability has been resolved:

dcache: don't put a mountpoint on a dentry that's being removed

rmdir(), unlink() and rename() call dontmount() on the victim and then detachmounts() with the victim's inode locked. dolockmount() takes the inode lock of the mountpoint and checks cantmount() so a mount can't show up after detachmounts().

But attachrecursivemnt() makes a second mountpoint for the root of the source mount so that the mounts already located at the destination can be put on top of it. No inode is locked for that one and dsetmounted() only refuses a dentry that is unlinked. Between detachmounts() and ddelete() the victim is still hashed:

rmrace: b passed dontmount() and detachmounts(), sleeping T2: movemount(S, /tmp/plcant/x, BENEATH) = 0 errno 0 () T1: rmdir(/tmp/plcant/d/b) = 0 errno 0 109 107 0:61 /d/b//deleted /tmp/plcant/x rw,relatime - tmpfs tmpfs rw 108 109 0:63 / /tmp/plcant/x rw,relatime - tmpfs T rw

A bind mount of the directory that's being removed is moved beneath an existing mount while the rmdir() is located between the two calls. The mount ends up on the removed directory and nothing will ever detach it.

Check cantmount() in dsetmounted() as well. dontmount() raises the flag under dlock before detachmounts() runs so either the mountpoint is set first and detachmounts() finds the mount or the flag is seen and the mount is refused.