cbcvebase.
CVE-2025-37988
published 2025-05-20

CVE-2025-37988: 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…

PriorityP417medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.13%
2.9th percentile
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 u

Affected

27 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.27-1 (forky)linux 6.12.27-1 (forky)
linuxlinux
linuxlinux>= 6ac392815628f317fcfdca1a39df00b9cc4ebc8b < 4f435c1f4c48ff84968e2d9159f6fa41f46cf9984f435c1f4c48ff84968e2d9159f6fa41f46cf998
linuxlinux>= 6ac392815628f317fcfdca1a39df00b9cc4ebc8b < a61afd54826ac24c2c93845c4f441dbc344875b1a61afd54826ac24c2c93845c4f441dbc344875b1
linuxlinux>= 6ac392815628f317fcfdca1a39df00b9cc4ebc8b < d4b21e8cd3d7efa2deb9cff534f0133e84f35086d4b21e8cd3d7efa2deb9cff534f0133e84f35086
linuxlinux>= 6ac392815628f317fcfdca1a39df00b9cc4ebc8b < 0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b60d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.27-16.12.27-1
linuxlinux_kernel>= 0 < 6.12.27-16.12.27-1
linuxlinux_kernel>= 0 < 6.8.0-100.1006.8.0-100.100
linuxlinux_kernel>= 0 < 6.14.0-22.226.14.0-22.22
linuxlinux_kernel>= 6.13 < 6.14.56.14.5
linuxlinux_kernel>= 6.5 < 6.6.896.6.89
linuxlinux_kernel>= 6.7 < 6.12.266.12.26
msrcazl3_kernel_6.6.85.1-4_on_azure_linux_3.0
msrcazl3_kernel_6.6.92.2-1_on_azure_linux_3.0
ubuntulinux-aws
ubuntulinux-aws-6.8
ubuntulinux-gkeop
ubuntulinux-nvidia
ubuntulinux-nvidia-6.8
ubuntulinux-oracle
ubuntulinux-oracle-6.8

CVSS provenance

nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv4.7MEDIUM
vendor_msrc7.0HIGH
vendor_debian4.7LOW
vendor_redhat4.7MEDIUM
vendor_ubuntu3.2LOW
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.