Cloudanix VulnDB

CVE-2026-98996

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the operating system's handling of shared storage mounts can let an unmount operation remove access that another process is still actively using, which may break applications or weaken isolation between environments.

Chainable
Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The propagate_mount_busy() helper fails to inspect copies of a victim mount that have two or more children or a single non-overmount child, allowing synchronous unmounts to detach mounts that remain referenced via open file descriptors or nested propagation chains.

Why it matters to the business

Containers sharing mount trees with the host may lose access to active mounts without warning, causing application failures, data inconsistency, or unintended exposure of filesystem state across isolation boundaries.

How an attack unfolds

An attacker configures a shared mount tree, uses unshare and move_mount to place a detached copy beneath a propagated mount inside a container, keeps an open file descriptor to the tree, then triggers a host-level umount that succeeds because the busy check is incomplete, silently removing the in-use mount from the container namespace.

How to fix it

Apply the upstream kernel commit that updates propagate_mount_busy() to walk master chains and apply the same single-victim-without-children checks used by propagate_umount(). Rebuild and deploy the patched kernel on all affected hosts and container runtimes.

How to confirm the fix worked

Confirm the patched propagate_mount_busy() performs the chain walk from each top-level master and checks every copy for references before allowing a synchronous unmount; reproduce the provided mountinfo scenario and verify the umount now fails when the tree is still referenced.

Typical attack path

  1. Create and share a tmpfs mount tree between host and container
  2. Make the mount shared or slave as needed for propagation
  3. Inside the container, clone the tree with open_tree and move it beneath a propagated mount point
  4. Retain an open file descriptor to the moved tree
  5. Trigger a synchronous umount on the host mount point
  6. Observe the mount disappear from container mountinfo while the file descriptor remains valid

How to detect it

Review /proc/self/mountinfo and container mount namespaces after host-initiated umount calls for mounts that disappear while open file descriptors or child mounts still reference them; correlate with container creation events involving mount propagation flags.

What your security team should do

  • Prioritize kernel updates on systems running containers that share mount namespaces with the host
  • Audit container runtime configurations for use of OPEN_TREE_CLONE combined with MOVE_MOUNT_BENEATH
  • Add monitoring for unexpected mount detachments in /proc/*/mountinfo around unmount events
  • Test the fix in staging environments that replicate host-container mount propagation

The record

In the Linux kernel, the following vulnerability has been resolved: fs: don't silently unmount busy mounts The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ended up adding covered mounts to both sides in one go. Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") and that started to unmount more than before: [1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted. So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn't look at copies of the victim that have two or more children nor a single child that is not the overmount. So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use. A container can run into this with its own mounts. The host shares a tree with the container and the host has a mount in that tree: mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a The container's /mnt is a slave copy of the host mount. The container now takes a detached copy of the tree and mounts that copy beneath its propagated copy of /mnt/a and keeps the file descriptor to the tree open: unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH) grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647 The now attached tree (777) is now mounted beneath the container's copy of /mnt/a. That's also where the host mount sits (as seen from the host mount namespace). So the propagated copy (776) of the host's mount is on top of its root and the copy of that (778) is inside it. Now the host runs: umount /mnt/a and it succeeds. The moved tree tree and the copy inside of it are gone from the container. Now only the propagated copy is left and it got reparented to where it was before: grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ... But the file descriptor still refers to the moved tree. So a synchronous umount detached a mount that is still in use. Teach propagate_mount_busy() the same checks that propagate_umount() does. It now checks for a single victim mount without children for which it can assume that MNT_LOCKED is cleared on every copy like propagate_umount() does. The copies form chains. IOW, when a copy itself receives propagation from the victim's parent then the mount at the same mountpoint inside that copy is a copy as well. Whether a mount receives propagation from the victim's can simply be checked by walking its masters. Walk each chain once from its top so we are sure that nested copies stay linear. Check every reference once of every copy that gets unmounted.

Affected packages

Ecosystem Package Introduced Fixed