# CVE-2026-98984: dcache: don't put a mountpoint on a dentry that's being removed - **Severity:** Not scored - **Exploited in the wild:** Not known - **Fix available:** Yes - **Published:** 23 Oct 2026 - **Updated:** 23 Oct 2026 - **Also known as:** AZL-110819, BELL-CVE-2026-98984, DEBIAN-CVE-2026-98984, GHSA-j5f8-8hqx-2hcr, UBUNTU-CVE-2026-98984 ## What is CVE-2026-98984? CVE-2026-98984 is a vulnerability in Linux, published on 23 Oct 2026. ### Official 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. ## Which versions are affected by CVE-2026-98984? ## How do I fix CVE-2026-98984? Upgrade to a fixed version. ## Is CVE-2026-98984 being exploited? There is no known exploitation of CVE-2026-98984 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2026-98984 and fix it if it is affected. What it is: CVE-2026-98984 is a vulnerability in Linux, published on 23 Oct 2026. Exploitation: There is no known exploitation of CVE-2026-98984 in the wild and no public exploit code. Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2026-98984/ (Markdown: https://insights.sbomify.com/CVE-2026-98984/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2026-98984 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-98984 - OSV: https://osv.dev/vulnerability/CVE-2026-98984 --- From sbomify Insights: https://insights.sbomify.com/CVE-2026-98984/ Summaries are generated and may contain mistakes; the official description above is the record.