CVE-2026-98984: Linux kernel · dcache: don't put a mountpoint on a dentry that's being removed
Source GCVE Database
Not known to be exploited · fixed in 793cb67b0f52d00c67bd0e76bc57455b5c70ebb8 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 14:05 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 793cb67b0f52d00c67bd0e76bc57455b5c70ebb8, 390ddcea2a8aca411b931a8e2863a80ccca8d2b3, 75f4197f1e11d2eb75c2d6f916a7d4764db621e5 +6
Exploitation evidence
Disclosed: evidence found.
CVE published 23 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
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.
References
- nvd.nist.gov/vuln/detail/CVE-2026-98984 (opens in a new tab)
- git.kernel.org/stable/c/30a1625022411a387cce9239408ece9955bc9c58 (opens in a new tab)
- git.kernel.org/stable/c/390ddcea2a8aca411b931a8e2863a80ccca8d2b3 (opens in a new tab)
- git.kernel.org/stable/c/5e6bfd9f249f2c74bb63c0f06ad959da3bee0971 (opens in a new tab)
- git.kernel.org/stable/c/75f4197f1e11d2eb75c2d6f916a7d4764db621e5 (opens in a new tab)
- git.kernel.org/stable/c/793cb67b0f52d00c67bd0e76bc57455b5c70ebb8 (opens in a new tab)