---
id: "CVE-2026-98984"
kind: "vulnerability"
aliases: ["CVE-2026-98984"]
title: "Linux kernel: mount race lets a bind mount land on a deleted directory"
severity: "unknown"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["containers", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: ["default-config"]
published_at: "2026-10-23T13:17:20+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98984", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98984", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: mount race lets a bind mount land on a deleted directory

A race in the Linux kernel's mount code lets a bind mount be attached to a directory while another process is removing it with rmdir(), unlink() or rename(). The mount then sits on a deleted directory that nothing detaches, which can leave a stale mount in place.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the kernel version your distribution lists as fixed for CVE-2026-98984
- Check whether unprivileged user namespaces or mount operations are reachable on the host, for example `sysctl kernel.unprivileged_userns_clone` where that knob exists

## Fix

- Update the kernel to a build from your distribution that includes the upstream commit for CVE-2026-98984, then reboot
- unknown for exact fixed versions: the sources do not name them

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98984
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98984

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_