CVE-2026-98991 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
namespace: queue a mount only once for mount notifications
mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't.
propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time.
The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory:
BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40
This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace with a FAN_MARK_MNTNS mark does the rest and root in a user namespace can have both.
Initialize to_notify in alloc_vfsmnt() and leave a mount alone that is queued already. mnt_notify() looks at the state the mount has when the list is drained so a single entry per mount is enough. The move event for a mount that is unmounted under the same hold is lost. That's fine. The detach is what matters.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The Linux kernel contains a critical race condition within its filesystem namespace notification subsystem, specifically involving the management of mount point notifications during complex unmount operations. This vulnerability arises from a flaw in how mounts are queued for notification when they are being removed or reparented. The function mnt_notify_add is responsible for adding a mount to a notify_list so that interested parties can be alerted about changes. However, this function does not verify whether the specific mount has already been added to the list during the current hold of namespace_sem. While the kernel logic assumes that each mount will only be queued once per critical section, this assumption is violated under certain conditions involving recursive unmounts and reparenting operations.
The root cause lies in the interaction between propagate_umount, shrink_submounts, and mark_mounts_for_expiry functions. These functions operate within a single namespace_sem hold but may invoke umount_tree multiple times for different sets of mounts. When an overmount survives an unmount operation, it is moved off a stack of dying mounts and queued as moved. If the first invocation of umount_tree reparents a mount that is subsequently targeted by a second invocation of umount_tree within the same critical section, the mount can be reparented again and consequently added to the notification list for a second time. This double-queuing creates a corrupted doubly-linked list structure because the second call to list_add_tail effectively cuts off any mounts queued between the first and second additions while leaving the head pointer directed at the last entry.
This structural corruption leads directly to severe memory safety violations, specifically slab-use-after-free errors detected by Kernel Address Sanitizer (KASAN). When notify_mnt_list iterates over the corrupted list, it only visits the final mount in the chain, causing intermediate mounts to be freed while still being referenced by the notification list pointers. Subsequent filesystem operations on the host system then attempt to access this freed memory, resulting in kernel panics or potential exploitation vectors for arbitrary code execution. The vulnerability is particularly exploitable when dealing with mounts that possess the MNT_SHRINKABLE flag, such as submounts of NFS, AFS, CIFS, and tracefs mounts beneath debugfs. Bind mounts inherit this flag, allowing an attacker to craft specific mount namespace configurations involving FAN_MARK_MNTNS marks within a user namespace to trigger the condition from unprivileged contexts if root privileges are available in that namespace.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free and CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization (Race Condition). In terms of the MITRE ATT&CK framework for Linux systems, this flaw relates to techniques involving resource manipulation during lifecycle events, potentially allowing an attacker to disrupt service availability through kernel crashes or escalate privileges by exploiting memory corruption. The impact is significant as it compromises system stability and integrity, requiring immediate attention from distribution maintainers and upstream developers.
The resolution involves modifying the allocation logic for virtual filesystem mount structures in alloc_vfsmnt to initialize a state flag indicating whether a mount has already been queued for notification. By checking this state before adding a mount to the notify list, the kernel ensures that each mount is processed only once per critical section, thereby preventing the double-queuing issue and subsequent memory corruption. Although this fix results in the loss of move events for mounts unmounted under the same hold, this trade-off is acceptable because the detach event carries the necessary semantic information for notification consumers. System administrators should apply kernel updates that include this patch to mitigate the risk of local denial-of-service attacks or potential privilege escalation exploits derived from these memory safety violations.