CVE-2025-37988

一、漏洞信息
 漏洞编号：[CVE-2025-37988](https://nvd.nist.gov/vuln/detail/CVE-2025-37988)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：N/A None
  Vector：CVSS：3.0/
 漏洞简述：
  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 thatlocation 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 themountpoint of path->mnt.  The thing is, without sufficient locking->mnt_parent may change under us and none of the locks are heldat that point.  The rules are	* mount_lock stabilizes m->mnt_parent for any mount m.	* namespace_sem stabilizes m->mnt_parent, provided thatm 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() hasto take inode_lock() before grabbing namespace_sem.  It doesrecheck that path->mnt is still mounted in the same place aftergetting 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 casedentry would no longer be a mountpoint and could ve been evictedon memory pressure along with its inode - not something you wantwhen grabbing lock on that inode.However, pinning a dentry is not enough - the matching mount isalso pinned only by the fact that path->mnt is mounted on top itand at that point we are not holding any locks whatsoever, sothe same kind of races could end up with all references tothat mount gone just as we are about to enter inode_lock().If that happens, we are left with filesystem being shut down whilewe 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 gettingshut down under us.  After taking namespace_sem we verify thatpath->mnt is still mounted (which stabilizes its ->mnt_parent) andcheck that it s still mounted at the same place.  From that pointon to the matching namespace_unlock() we are guaranteed thatmount/dentry pair we d grabbed are also pinned by being the mountpointof path->mnt, so we can quietly drop both the dentry reference (asthe 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 untilthe namespace_unlock().  That s easy to fix - just have inode_unlock()done earlier, while it s still pinned by mp->m_dentry.
 漏洞公开时间：2025-05-21 02:15:45
 漏洞创建时间：2025-05-21 02:46:23
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2025-37988
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/4f435c1f4c48ff84968e2d9159f6fa41f46cf998 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a61afd54826ac24c2c93845c4f441dbc344875b1 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d4b21e8cd3d7efa2deb9cff534f0133e84f35086 |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-37988 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2025/CVE-2025-37988.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://git.kernel.org/stable/c/4f435c1f4c48ff84968e2d9159f6fa41f46cf998 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://git.kernel.org/stable/c/a61afd54826ac24c2c93845c4f441dbc344875b1 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://git.kernel.org/stable/c/d4b21e8cd3d7efa2deb9cff534f0133e84f35086 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://git.kernel.org/stable/c/0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2025-37988 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2367608 | https://bugzilla.suse.com/show_bug.cgi?id=1243521 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2025052038-CVE-2025-37988-1fa1@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2367608 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2025-37988 |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  openBrain开源漏洞感知系统
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
| linux_kernel | 6.6.89 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4f435c1f4c48ff84968e2d9159f6fa41f46cf998Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6ac392815628f317fcfdca1a39df00b9cc4ebc8b | linuxkernelcves |
| linux_kernel | 6.12.26 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a61afd54826ac24c2c93845c4f441dbc344875b1Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6ac392815628f317fcfdca1a39df00b9cc4ebc8b | linuxkernelcves |
| linux_kernel | 6.14.5 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d4b21e8cd3d7efa2deb9cff534f0133e84f35086Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6ac392815628f317fcfdca1a39df00b9cc4ebc8b | linuxkernelcves |
| linux_kernel | 6.15-rc4 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6Please | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6ac392815628f317fcfdca1a39df00b9cc4ebc8b | linuxkernelcves |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  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 thatlocation 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 themountpoint of path->mnt.  The thing is, without sufficient locking->mnt_parent may change under us and none of the locks are heldat that point.  The rules are* mount_lock stabilizes m->mnt_parent for any mount m.* namespace_sem stabilizes m->mnt_parent, provided thatm 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() hasto take inode_lock() before grabbing namespace_sem.  It doesrecheck that path->mnt is still mounted in the same place aftergetting 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 casedentry would no longer be a mountpoint and could ve been evictedon memory pressure along with its inode - not something you wantwhen grabbing lock on that inode.However, pinning a dentry is not enough - the matching mount isalso pinned only by the fact that path->mnt is mounted on top itand at that point we are not holding any locks whatsoever, sothe same kind of races could end up with all references tothat mount gone just as we are about to enter inode_lock().If that happens, we are left with filesystem being shut down whilewe 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 gettingshut down under us.  After taking namespace_sem we verify thatpath->mnt is still mounted (which stabilizes its ->mnt_parent) andcheck that it s still mounted at the same place.  From that pointon to the matching namespace_unlock() we are guaranteed thatmount/dentry pair we d grabbed are also pinned by being the mountpointof path->mnt, so we can quietly drop both the dentry reference (asthe 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 untilthe namespace_unlock().  That s easy to fix - just have inode_unlock()done earlier, while it s still pinned by mp->m_dentry.
 openEuler评分：
  3.9
 Vector：CVSS：3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
 受影响版本排查(受影响/不受影响)：
  1.openEuler-24.03-LTS:受影响
2.openEuler-24.03-LTS-SP1(6.6.0):受影响
3.openEuler-24.03-LTS-SP2(6.6.0):受影响
4.master(6.6.0):不受影响
5.openEuler-20.03-LTS-SP4(4.19.90):不受影响
6.openEuler-22.03-LTS-SP3:不受影响
7.openEuler-22.03-LTS-SP4:不受影响
8.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.master(6.6.0):否
2.openEuler-20.03-LTS-SP4(4.19.90):否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-24.03-LTS-SP1(6.6.0):否
8.openEuler-24.03-LTS-SP2(6.6.0):否

原因说明：
  1.openEuler-24.03-LTS:正常修复
2.openEuler-24.03-LTS-SP1(6.6.0):正常修复
3.openEuler-24.03-LTS-SP2(6.6.0):正常修复
4.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
6.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
7.openEuler-22.03-LTS-SP3:不受影响-漏洞代码不存在
8.openEuler-22.03-LTS-SP4:不受影响-漏洞代码不存在

三、漏洞修复
安全公告链接：https://www.openeuler.org/zh/security/safety-bulletin/detail/?id=openEuler-SA-2025-1595

src-openEuler/kernel

内容风险标识

评论 (7)

src-openEuler/kernel .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2025-37988

评论 (7)

搜索帮助

src-openEuler/kernel