CVE-2026-98990 in Linux
Summary
by MITRE • 10/23/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel contains a race condition vulnerability within its filesystem namespace management logic, specifically affecting the handling of submounts during unmount operations. This issue arises from the sequence in which mounts are processed for expiration and removal. The functions shrink_submounts() and mark_mounts_for_expiry() operate by first collecting all eligible mounts into a list before proceeding to unmount them sequentially. While the kernel checks if a mount is busy using propagate_mount_busy(), this check occurs prior to any structural changes to the mount tree. However, the act of unmounting the first mount in the sequence alters the topology of the mount namespace that subsequent mounts rely on for propagation logic.
When the first mount is removed, propagate_umount() relocates a surviving overmount from the copy being unmounted and attaches it to the location where the original copy was mounted. This structural shift can cause an overmount to become associated with the context of a second victim mount in the list. Because this newly positioned overmount may appear childless after the relocation, the trim_one() function proceeds to commit its removal without verifying its current reference count or usage status. Consequently, a synchronous unmount operation can inadvertently remove a busy mount that is still actively referenced elsewhere in the system, marking it with MNT_SYNC_UMOUNT while users are still accessing it.
This flaw primarily impacts mounts designated as shrinkable, which include automounted submounts for network file systems such as NFS, AFS, and CIFS, as well as tracefs mounts located under debugfs. Bind mounts also inherit this flag, making them susceptible to the same issue. In practice, attempting two consecutive unmount operations on affected paths may succeed in removing a busy mount when it should fail with an EBUSY error, or conversely, cause unexpected state inconsistencies where resources are freed while still in use. This behavior violates standard filesystem safety guarantees and can lead to data corruption or kernel instability if the underlying storage is accessed after premature removal.
The vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as it involves a race condition between reference counting checks and structural modifications during unmount sequences. From an ATT&CK perspective, this could be leveraged in scenarios involving local privilege escalation or denial of service by manipulating mount namespaces to destabilize the kernel state or access freed memory regions if subsequent allocations reuse the compromised structures.
To mitigate this vulnerability, each mount must now be checked for active references immediately before it is unmounted, ensuring that these checks occur under the same namespace_sem and mount_lock holds as the unmount operation itself. This synchronization ensures that reference counts are validated against the current state of the mount tree rather than a stale snapshot taken earlier in the process. The fix maintains linear algorithmic complexity to prevent performance degradation while guaranteeing that no busy mounts are prematurely removed, thereby preserving data integrity and system stability during complex namespace manipulations.