CVE-2026-98995

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

namespace: reset the old parent's ->overmount in mnt change mountpoint()

umount mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt change mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it.

For a mount that is moved beneath in attach recursive mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it.

It matters for reparent() though. propagate umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed.

do lock mount() follows ->overmount from the target path under mount lock. With a file descriptor on such a mount as the target of a mount beneath topmost overmount() walks into the freed mount and do lock mount() takes references on whatever it finds there.

So reset ->overmount of the old parent in mnt change mountpoint() the same way umount mnt() does. A mount's ->overmount is then always a mount that is attached to it.