Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 修复 由 do_move_mount() 处理的 MNT_TREE_BENEATH 中的几个争用情况 do_lock_mount(path, _) 会锁定由 *path 固定的挂载点在匹配 unlock_mount() 解锁该位置时仍由相同内容固定。不幸的是，对于“低于”的情况，情况不再那么简单 - 被锁定的对象不是 *path 指向的对象。它是 path->mnt 的挂载点。问题是如果没有足够的锁定->mnt_parent 可能会在我们的控制下发生变化并且此时不会持有任何锁定。
    规则如下 * mount_lock 稳定任何挂载 m->mnt_parent 的 m。 * namespace_sem 稳定 m->mnt_parent前提是已挂载 m。 * 如果上述任一条件成立且 m 的 refcount 为正数则保证 m->mnt_parent 的 refcount 也为正数。 namespace_sem 嵌套在 inode_lock() 内部因此 do_lock_mount() 必须先获取 inode_lock()然后再获取 namespace_sem。它会在获取 namespace_sem 之后重新检查 path->mnt 是否仍挂载在相同位置并且会注意固定 dentry。这是必需的因为否则我们可能会在获得锁定时以争用挂载 --move 或 umount 告终在这种情况下dentry 将不再是一个挂载点并且可能在内存压力下与其 inode 一起被驱逐 - 这不是您想要该 inode 上的锁时所希望的情况。但是固定 dentry 是不够的 - 仅通过在顶部挂载了 path->mnt 匹配的挂载也才会固定并且此时我们无论如何不会保持任何锁定因此同种争用可能会当我们即将进入 inode_lock() 时对该挂载的所有引用均消失。如果发生这种情况我们将在保留文件系统上的 dentry 引用时导致文件系统关闭结果不太好。我们需要做的是同时抓取 dentry 和 mount使 inode_lock() 安全
    *和*避免 fs 在 us 下关闭的问题。获取 namespace_sem 后我们验证是否仍挂载了 path->mnt这可稳定其 ->mnt_parent并检查其是否仍然在相同位置挂载。从该点到匹配的 namespace_unlock()我们保证通过成为 path->mnt 的挂载点来固定我们已抓取的挂载/dentry 对因此我们可以悄悄地终止这两个 dentry 引用正如当前代码的和 mnt 一个 - 由于我们不会丢弃最终的 refs因此可在 namespace_sem 下执行。以上即解决了 do_lock_mount() 端的问题unlock_mount() 也有一个目录项因为 dentry 保证只在 namespace_unlock() 调用之前保持锁定状态。这很容易修复 - 只要在仍由 mp->m_dentry 固定时提前完成 inode_unlock() 即可。 (CVE-2025-37988)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-37988

medium Nessus 插件 ID 249754

版本 1.8