Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

nvd логотип

CVE-2025-37988

Опубликовано: 20 мая 2025
Источник: nvd
CVSS3: 4.7
EPSS Низкий

Описание

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-

Уязвимые конфигурации

Конфигурация 1

Одно из

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Версия от 6.5 (включая) до 6.6.89 (исключая)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Версия от 6.7 (включая) до 6.12.26 (исключая)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Версия от 6.13 (включая) до 6.14.5 (исключая)
cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*

EPSS

Процентиль: 1%
0.00012
Низкий

4.7 Medium

CVSS3

Дефекты

CWE-362

Связанные уязвимости

CVSS3: 4.7
ubuntu
7 месяцев назад

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...

CVSS3: 7
redhat
7 месяцев назад

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...

CVSS3: 7
msrc
6 месяцев назад

fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()

CVSS3: 4.7
debian
7 месяцев назад

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

CVSS3: 4.7
github
7 месяцев назад

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 pa...

EPSS

Процентиль: 1%
0.00012
Низкий

4.7 Medium

CVSS3

Дефекты

CWE-362