From: Al Viro <viro@zeniv.linux.org.uk> stable inclusion from stable-v6.6.92 commit d8ece4ced3b051e656c77180df2e69e19e24edc1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICGANV CVE: CVE-2025-38058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=t... -------------------------------- [ 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> Signed-off-by: Long Li <leo.lilong@huawei.com> --- fs/namespace.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 6f1741379324..b682a044cf0e 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -578,12 +578,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; -- 2.39.2