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.
Published: 2026-10-23
Score: 3.3 Low
EPSS: < 1% Very Low
KEV: No
Impact: Race condition leading to mount point hijacking
Action: Immediate Patch
AI Analysis

Impact

The vulnerability is a thread‑safety defect in the Linux kernel’s dentry cache handling. When a directory is being removed by rmdir(), unlink(), or rename(), a race condition can allow a separate bind mount operation to occur between the checks that prevent a mount at the target pathname and the actual detachment of the mount. The result is that a new mount point can be created on a dentry that is in the process of deletion, leaving a mount that references a vanished directory. Based on the description, it is inferred that an attacker can establish a mount that persists after the original pathname has been removed, potentially enabling access to files that were not intended to be exposed after deletion.

Affected Systems

All Linux kernel versions that contain the unpatched race condition are affected. The issue arises in the core kernel; any distribution using a kernel revision before the patches referenced in the advisory (e.g., commits 30a1625, 390ddce, 5e6bfd9, 75f4197, 793cb67) includes the vulnerability. Because the kernel is common to all Linux distributions, the impact applies to all vendor implementations of Linux.

Risk and Exploitability

Based on the description, it is inferred that a local user with sufficient privileges to perform bind mounts (e.g., CAP_SYS_ADMIN) can trigger the race and create a mount at a deleted path. The CVSS score is 3.3, the EPSS score is < 1%, and the vulnerability is not listed in CISA KEV. While the defect could be used to expose files or facilitate privilege escalation, the CVE description does not explicitly state these outcomes; thus, this inference is made based on the described race condition. The exploitation requires simultaneous operations on the same dentry and an ability to perform bind mounts, which are non‑trivial but within the capabilities of a privileged user.

Generated by OpenCVE AI on October 29, 2026 at 22:36 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version including the referenced patches (e.g., commits 30a1625, 390ddce, 5e6bfd9, 75f4197, or 793cb67).
  • Restrict bind‑mount and mount operations to trusted accounts by limiting CAP_SYS_ADMIN or using namespace isolation.
  • Monitor the system for unexpected mount points on deleted directories with tools such as "mount" or "findmnt" and investigate any anomalies.

Generated by OpenCVE AI on October 29, 2026 at 22:36 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-9018-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9018-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9022-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9023-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9024-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9025-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9026-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9039-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-9040-1 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-9066-1 Linux kernel (HWE) vulnerabilities
History

Fri, 30 Oct 2026 13:00:00 +0000


Thu, 29 Oct 2026 20:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-366
References
Metrics threat_severity

None

cvssV3_1

{'score': 3.3, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L'}

threat_severity

Low


Sat, 24 Oct 2026 08:30:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 17:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617

Fri, 23 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
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.
Title dcache: don't put a mountpoint on a dentry that's being removed
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-30T12:40:42.302Z

Reserved: 2026-09-25T10:25:14.384Z

Link: CVE-2026-98984

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:20.287

Modified: 2026-10-30T13:21:34.167

Link: CVE-2026-98984

cve-icon Redhat

Severity : Low

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-98984 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T22:45:03Z

Weaknesses
  • CWE-366

    Race Condition within a Thread