CVE-2026-98984

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can let an attacker attach a hidden mount to a folder while it is being deleted, potentially leaving behind inaccessible or unexpected filesystem attachments.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Moderate
Impact: Privilege Gain
Component: OS kernel
Class: Race Condition
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Race condition in Linux kernel dcache allows attach_recursive_mnt to create a second mountpoint on a dentry between dont_mount/detach_mounts and d_delete, bypassing cant_mount checks so a mount persists on a removed directory.

Why it matters to the business

May cause persistent mounts on deleted paths leading to filesystem leaks, container escape risks, or operational instability in environments with concurrent bind mounts and directory removals; low exploit maturity but affects core kernel used widely.

How an attack unfolds

Attacker runs one thread performing rmdir/unlink/rename on a target directory while a second thread issues move_mount to place a bind mount beneath it during the brief window after detach_mounts but before d_delete, leaving an undetachable mount on the victim dentry.

How to fix it

Apply the upstream kernel patch adding a cant_mount check inside d_set_mounted; rebuild and deploy updated kernel images to all affected systems.

How to confirm the fix worked

Inspect d_set_mounted implementation for the added cant_mount guard and confirm no mounts remain attached to concurrently removed dentries under load testing.

Typical attack path

Locate or create a directory suitable for the race
Spawn concurrent threads for removal operation and move_mount beneath
Trigger the race between dont_mount and d_set_mounted
Observe resulting mount entry on the now-deleted path

How to detect it

Review /proc/mounts and kernel logs for mounts referencing deleted paths or /deleted entries appearing after concurrent rmdir and move_mount activity; correlate with auditd mount syscalls.

What your security team should do

Prioritize kernel updates on systems with heavy bind-mount or container usage
Restrict unprivileged mount capabilities via user namespaces or SELinux
Monitor EPSS and KEV status for any rise in exploit activity

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed