CVE-2026-98985 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
namespace: check the mounts before reading their parents in pivot_root()
path_pivot_root() reads the parents of new_root and of the caller's root and checks whether they are shared before it checks that either mount is in the caller's mount namespace. Only namespace_sem is held. That's fine for a mount that is in the caller's mount namespace.
But new_root can be a file descriptor to a mount that has been unmounted and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted nothing pins the parent for it. The final mntput() of the parent unhooks the children under mount_lock alone and frees the parent afterwards:
pivot_root() close(fd), last ref on the parent ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath() __umount_mnt(new_mnt) cleanup_mnt() call_rcu() IS_MNT_SHARED(ex_parent)
BUG: KASAN: slab-use-after-free in path_pivot_root+0xf1a/0x1840 Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157 path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190
The same goes for the caller's root via chroot(). Both outcomes of the check end in EINVAL so nothing but the read itself goes wrong. It's the same thing commit bb4609405752 ("statmount: read the parent of an unmounted mount under mount_lock") fixed for statmount().
Check that both mounts are in the caller's namespace before their parents are read. Every path returns EINVAL either way.
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 vulnerability identified involves a race condition within the pivot_root system call, specifically affecting how mount namespaces and parent references are handled during root filesystem transitions. The core technical flaw lies in the sequence of operations performed by the path_pivot_root function. Under normal circumstances, when pivoting to a new root, the kernel must verify that both the old caller's root and the proposed new_root are within the same mount namespace before proceeding with structural changes. However, prior to this fix, the implementation checked whether these mounts were shared across namespaces before verifying their presence in the caller's specific mount namespace. This ordering created a critical window of vulnerability where an attacker could exploit the timing between checking for shared status and confirming namespace ownership.
The danger arises specifically when new_root is specified as a file descriptor pointing to a mount that has been unmounted but remains alive solely due to open file descriptors holding references to it. In such scenarios, if the unmounting process detaches the mount from its parent without proper pinning mechanisms in place for namespace checks, the parent structure can be freed prematurely. The kernel's memory management subsystem may invoke mntput_no_expire_slowpath and subsequently cleanup_mnt, which schedules the final release of the parent mount via call_rcu. If path_pivot_root attempts to read ex_parent after this point but before the RCU grace period completes, it triggers a slab-use-after-free error detected by KASAN. This occurs because the code reads from memory that has already been freed or is in the process of being reclaimed, leading to potential kernel crashes or undefined behavior.
Although the immediate outcome of both branches resulting from this race condition is an EINVAL error return, indicating invalid arguments, the act of reading freed memory constitutes a serious security flaw. Use-after-free vulnerabilities are particularly dangerous as they can potentially be leveraged for arbitrary code execution if an attacker can control the contents of the reclaimed slab cache or manipulate timing to access sensitive data before it is overwritten. The vulnerability affects not only pivot_root but also similar operations like chroot, where analogous logic regarding mount namespace verification and parent reference handling exists. This issue mirrors a previously addressed problem in statmount, as seen in commit bb4609405752, which corrected the order of operations to ensure parents are read under appropriate locks when dealing with unmounted mounts.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, where memory is accessed after it has been freed, leading to unpredictable behavior and potential exploitation. In terms of attack vectors, this relates to ATT&CK technique T1059, Command and Scripting Interpreter, if the resulting instability or crash is used for denial-of-service, though more critically, use-after-free flaws often serve as primitives for privilege escalation (T1068) by allowing attackers to corrupt kernel memory structures. The operational impact includes system instability through kernel panics caused by KASAN-detected errors and potential security breaches if the race condition can be precisely timed to exploit the freed memory state.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that reorders the namespace checks. By verifying that both mounts reside within the caller's mount namespace before attempting to read their parent structures, the window for the race condition is eliminated. System administrators should ensure that all systems are updated with the latest stable kernel versions containing this fix. Additionally, developers utilizing pivot_root or chroot in custom applications should be aware of these constraints and avoid passing file descriptors to unmounted mounts unless absolutely necessary, ensuring proper reference counting and namespace isolation practices are followed during filesystem operations.