]> git.ipfire.org Git - thirdparty/kernel/stable.git/commitdiff
__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
authorAl Viro <viro@zeniv.linux.org.uk>
Sun, 27 Apr 2025 19:41:51 +0000 (15:41 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 29 May 2025 09:13:54 +0000 (11:13 +0200)
[ Upstream commit 250cf3693060a5f803c5f1ddc082bb06b16112a9 ]

... or we risk stealing final mntput from sync umount - raising mnt_count
after umount(2) has verified that victim is not busy, but before it
has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
that it's safe to quietly undo mnt_count increment and leaves dropping
the reference to caller, where it'll be a full-blown mntput().

Check under mount_lock is needed; leaving the current one done before
taking that makes no sense - it's nowhere near common enough to bother
with.

Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/namespace.c

index 5b84e29613fe4d0edb4ebf9ee3c7dbcbe307a677..1d950974d67ee8e35b67d863d6f04df197f70996 100644 (file)
@@ -781,12 +781,8 @@ int __legitimize_mnt(struct vfsmount *bastard, unsigned seq)
        smp_mb();               // see mntput_no_expire() and do_umount()
        if (likely(!read_seqretry(&mount_lock, seq)))
                return 0;
-       if (bastard->mnt_flags & MNT_SYNC_UMOUNT) {
-               mnt_add_count(mnt, -1);
-               return 1;
-       }
        lock_mount_hash();
-       if (unlikely(bastard->mnt_flags & MNT_DOOMED)) {
+       if (unlikely(bastard->mnt_flags & (MNT_SYNC_UMOUNT | MNT_DOOMED))) {
                mnt_add_count(mnt, -1);
                unlock_mount_hash();
                return 1;