CVE-2026-98990

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A recent Linux kernel fix prevents certain network folder mounts from being unexpectedly removed while still in use, which could have disrupted file access or caused system problems.

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

What it actually does

Race condition in Linux kernel namespace mount handling allows shrink_submounts() and mark_mounts_for_expiry() to unmount a busy mount with active references after propagate_umount() alters the mount tree, incorrectly marking it MNT_SYNC_UMOUNT.

Why it matters to the business

Unexpected unmounts of active automounted network filesystems can disrupt ongoing operations, cause application failures, or trigger kernel instability on systems using NFS, AFS, CIFS, or debugfs.

How an attack unfolds

An attacker with local mount privileges issues concurrent umount operations against automountable submounts; the first umount alters the propagation tree so the second unmount bypasses reference checks and forcibly detaches a still-in-use mount.

How to fix it

Apply the upstream kernel patch that performs reference checks immediately before unmount under the same namespace_sem and mount_lock hold; rebuild and deploy updated kernels across all affected systems.

How to confirm the fix worked

Verify kernel source contains the updated check in shrink_submounts/mark_mounts_for_expiry before unmount; test repeated umount sequences on MNT_SHRINKABLE mounts to confirm EBUSY is returned instead of silent detachment.

Typical attack path

Identify or create automountable submounts (NFS/AFS/CIFS or tracefs under debugfs)
Issue first umount2() call that succeeds and modifies mount tree
Immediately issue second umount2() call that propagates into altered tree
Busy mount is detached without reference check and marked MNT_SYNC_UMOUNT

How to detect it

Search kernel logs and audit trails for sequences of successful umount2() calls followed by unexpected MNT_SYNC_UMOUNT markings or cwd unreachable errors on NFS/AFS/CIFS mounts; correlate with application I/O failures on those paths.

umount2(/tmp/plshrink/p1, 0) = 0
MNT_SYNC_UMOUNT
cwd is (unreachable)

What your security team should do

Prioritize kernel updates on all systems exposing NFS, AFS, CIFS, or debugfs automounts
Monitor mount-related kernel logs and umount failure rates for anomalies
Restrict unprivileged mount/unmount capabilities via user namespaces where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: namespace: check a submount for references right before unmounting it shrink_submounts() and mark_mounts_for_expiry() first collect all the mounts they are allowed to unmount and then unmount them. Whether a mount is busy is decided by propagate_mount_busy() on the tree. But unmounting the first mount changes the tree that the second one propagates into. propagate_umount() moves a surviving overmount off a copy it unmounts and mounts it where the copy was mounted. If that's where the propagated copy of the second victim is looked up the overmount becomes a candidate of the second umount_tree(). It's childless and so trim_one() commits it without looking at its reference count. So a synchronous umount pulls out a busy mount that is in use somewhere else and marks it MNT_SYNC_UMOUNT while it has users: umount2(/tmp/plshrink/p1, 0) = 0 errno 0 cwd is (unreachable) The same two umounts requested one after the other fail with EBUSY. This needs a mount with MNT_SHRINKABLE, i.e., automounted submounts of NFS, AFS and CIFS or the tracefs mount below debugfs. Bind mounts inherit the flag. Check each mount right before it is unmounted under the same hold of namespace_sem and mount_lock as the umount itself. Make sure that the algorithm stays linear.

Affected packages

Ecosystem	Package	Introduced	Fixed