CVE-2026-98991

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.