CVE-2025-37988

None

CVSS

—

EPSS

0.1%

Published

May 20, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel safely moves mount points could let a local user crash the system or gain extra access if left unfixed.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: High
Impact: Privilege Gain
Component: OS kernel
Class: Race Condition
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Race condition in do_move_mount() MNT_TREE_BENEATH handling allows mnt_parent to change without proper locking, leading to use of freed or invalid mount/dentry structures and potential filesystem shutdown while references are held.

Why it matters to the business

Linux systems using affected kernels may experience crashes, instability, or local privilege escalation; the issue affects Ubuntu Pro 18.04 LTS AWS instances until patched, increasing operational risk for unupdated environments.

How an attack unfolds

An attacker with local access crafts concurrent mount --move or umount operations to trigger the race during do_lock_mount(), causing the kernel to operate on stale mount structures; related Linux kernel privilege-escalation techniques seen in similar CVEs can be adapted to achieve code execution or denial of service.

How to fix it

Upgrade linux-aws-5.4 on Ubuntu Pro 18.04 LTS to version 5.4.0-1135.145~18.04.1 or later; apply the kernel update and reboot affected systems.

How to confirm the fix worked

Confirm the installed kernel package version matches or exceeds the fixed release and verify that the mount-related race fixes are present in the changelog or source.

Typical attack path

Obtain local unprivileged shell on target Linux system
Perform concurrent mount namespace manipulation to race do_move_mount()
Trigger mnt_parent change while locks are acquired
Exploit resulting invalid state for privilege escalation or crash

How to detect it

Review kernel logs for oops/panic messages involving mount structures or do_move_mount; correlate with unusual mount namespace activity from unprivileged processes.

What your security team should do

Immediately schedule patching of all linux-aws-5.4 instances to 5.4.0-1135.145~18.04.1
Restrict local mount namespace operations for untrusted users via SELinux/AppArmor or seccomp until patched
Monitor for kernel oops or mount-related crashes as potential exploitation indicators

The record

In the Linux kernel, the following vulnerability has been resolved: fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount() Normally do_lock_mount(path, _) is locking a mountpoint pinned by *path and at the time when matching unlock_mount() unlocks that location it is still pinned by the same thing. Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one *path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mnt_parent may change under us and none of the locks are held at that point. The rules are * mount_lock stabilizes m->mnt_parent for any mount m. * namespace_sem stabilizes m->mnt_parent, provided that m is mounted. * if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mnt_parent. namespace_sem nests inside inode_lock(), so do_lock_mount() has to take inode_lock() before grabbing namespace_sem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode. However, pinning a dentry is not enough - the matching mount is also pinned only by the fact that path->mnt is mounted on top it and at that point we are not holding any locks whatsoever, so the same kind of races could end up with all references to that mount gone just as we are about to enter inode_lock(). If that happens, we are left with filesystem being shut down while we are holding a dentry reference on it; results are not pretty. What we need to do is grab both dentry and mount at the same time; that makes inode_lock() safe *and* avoids the problem with fs getting shut down under us. After taking namespace_sem we verify that path->mnt is still mounted (which stabilizes its ->mnt_parent) and check that it's still mounted at the same place. From that point on to the matching namespace_unlock() we are guaranteed that mount/dentry pair we'd grabbed are also pinned by being the mountpoint of path->mnt, so we can quietly drop both the dentry reference (as the current code does) and mnt one - it's OK to do under namespace_sem, since we are not dropping the final refs. That solves the problem on do_lock_mount() side; unlock_mount() also has one, since dentry is guaranteed to stay pinned only until the namespace_unlock(). That's easy to fix - just have inode_unlock() done earlier, while it's still pinned by mp->m_dentry.

Affected packages

Ecosystem	Package	Introduced	Fixed
Debian:13	linux	0	6.12.27-1
Linux	Kernel	6.5.0	6.6.89
Mageia:9	dwarves	0	1.30-1.mga9
Mageia:9	kernel	0	6.6.93-1.mga9
Mageia:9	kernel-firmware	0	20250509-1.mga9
Mageia:9	kernel-firmware-nonfree	0	20250509-1.mga9.nonfree
Mageia:9	kernel-linus	0	6.6.93-1.mga9
Mageia:9	kmod-virtualbox	0	7.1.8-3.mga9
Mageia:9	kmod-xtables-addons	0	3.24-80.mga9
Mageia:9	libtraceevent	0	1.8.4-1.mga9
Mageia:9	libtracefs	0	1.8.2-1.mga9
Mageia:9	radeon-firmware	0	20250509-1.mga9.nonfree
Mageia:9	wireless-regdb	0	20250220-1.mga9