CVE-2026-98984: Linux Vulnerability

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.

Metrics

EPSS Probability

0.17%

6.2th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 1064f874abc0d05eeed8993815f584d847b72486, < 25e3ce3e2ebdd8ed3fc19dc1f7e3bc487f9240f3; >= 1064f874abc0d05eeed8993815f584d847b72486, < 982d231ad863bb14f7bda4852ab942c0203cec4b; >= 1064f874abc0d05eeed8993815f584d847b72486, < 96ca40461d8b91e13061ec4afb59bae6f07a516a; >= 1064f874abc0d05eeed8993815f584d847b72486, < 5e6bfd9f249f2c74bb63c0f06ad959da3bee0971; >= 1064f874abc0d05eeed8993815f584d847b72486, < 793cb67b0f52d00c67bd0e76bc57455b5c70ebb8; >= 1064f874abc0d05eeed8993815f584d847b72486, < 390ddcea2a8aca411b931a8e2863a80ccca8d2b3; >= 1064f874abc0d05eeed8993815f584d847b72486, < 30a1625022411a387cce9239408ece9955bc9c58; >= 1064f874abc0d05eeed8993815f584d847b72486, < 75f4197f1e11d2eb75c2d6f916a7d4764db621e5; 5e6ef5ef6eaf690faad3a7c6c665ebf45d7b6ccf; 839d42687dfce0ed0ea2c6bd8d707cc0e276fbe7; 808e83e5add13152bd4a88346487de68395c136b; 6de9d08a9718ee9c12ba6343c50141c2d633e3dc; >= 4.1.40, < 4.2; >= 4.4.54, < 4.5; >= 4.9.15, < 4.10; >= 4.10.3, < 4.11
Linux	Linux	4.11

References

Timeline

Published: Oct 23, 2026
Last Modified: Oct 30, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-98984?

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.

How severe is CVE-2026-98984?

Severity scoring for CVE-2026-98984 is pending analysis. The EPSS model estimates a 0.17% probability of exploitation in the next 30 days.

How do I fix CVE-2026-98984?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →