CVE-2026-98991: namespace: queue a mount only once for mount notifications

In the Linux kernel, the following vulnerability has been resolved:

namespace: queue a mount only once for mount notifications

mntnotifyadd() puts a mount on notifylist. 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 namespacesem hold. It isn't.

propagateumount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrinksubmounts() and markmountsforexpiry() call umounttree() for several mounts under a single namespacesem hold. So the second umounttree() 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 listaddtail() cuts the mounts queued in between out of the list while the head still points at the last of them. notifymntlist() then only visits that one mount and the others are freed after the grace period with notifylist still pointing at them. Every later mount operation on the host walks freed memory:

BUG: KASAN: slab-use-after-free in listaddvalidorreport Read of size 8 at addr ffff8881003d57e0 by task notifydq/162 listaddvalidorreport+0x15c/0x1a0 mntaddtons+0x322/0x890 attachrecursivemnt.isra.0+0xf2a/0x1a00 pathmount+0x139c/0x1d40

This needs a mount with MNTSHRINKABLE to bind from. That's what finishautomount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace with a FANMARKMNTNS mark does the rest and root in a user namespace can have both.

Initialize tonotify in allocvfsmnt() and leave a mount alone that is queued already. mntnotify() 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.