CVE-2024-45003

一、漏洞信息
 漏洞编号：[CVE-2024-45003](https://nvd.nist.gov/vuln/detail/CVE-2024-45003)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：4.7 Medium
  Vector：CVSS：3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:vfs: Don t evict inode under the inode lru traversing contextThe inode reclaiming process(See function prune_icache_sb) collects allreclaimable inodes and mark them with I_FREEING flag at first, at thattime, other processes will be stuck if they try getting these inodes(See function find_inode_fast), then the reclaiming process destroy theinodes by function dispose_list(). Some filesystems(eg. ext4 withea_inode feature, ubifs with xattr) may do inode lookup in the inodeevicting callback function, if the inode lookup is operated under theinode lru traversing context, deadlock problems may happen.Case 1: In function ext4_evict_inode(), the ea inode lookup could happen        if ea_inode feature is enabled, the lookup process will be stuck	under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this:    PA                              PB echo 2 > /proc/sys/vm/drop_caches  shrink_slab   prune_dcache_sb   // i_reg is added into lru, lru->i_ea->i_reg   prune_icache_sb    list_lru_walk_one     inode_lru_isolate      i_ea->i_state |= I_FREEING // set inode state     inode_lru_isolate      __iget(i_reg)      spin_unlock(&i_reg->i_lock)      spin_unlock(lru_lock)                                     rm file A                                      i_reg->nlink = 0      iput(i_reg) // i_reg->nlink is 0, do evict       ext4_evict_inode        ext4_xattr_delete_inode         ext4_xattr_inode_dec_ref_all          ext4_xattr_inode_iget           ext4_iget(i_ea->i_ino)            iget_locked             find_inode_fast              __wait_on_freeing_inode(i_ea) ----→ AA deadlock    dispose_list // cannot be executed by prune_icache_sb     wake_up_bit(&i_ea->i_state)Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file        deleting process holds BASEHD s wbuf->io_mutex while getting the	xattr inode, which could race with inode reclaiming process(The        reclaiming process could try locking BASEHD s wbuf->io_mutex in	inode evicting function), then an ABBA deadlock problem would	happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has    inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this:        PA                PB                        PC                echo 2 > /proc/sys/vm/drop_caches                 shrink_slab                  prune_dcache_sb                  // ib and ia are added into lru, lru->ixa->ib->ia                  prune_icache_sb                   list_lru_walk_one                    inode_lru_isolate                     ixa->i_state |= I_FREEING // set inode state                    inode_lru_isolate                     __iget(ib)                     spin_unlock(&ib->i_lock)                     spin_unlock(lru_lock)                                                   rm file B                                                    ib->nlink = 0 rm file A  iput(ia)   ubifs_evict_inode(ia)    ubifs_jnl_delete_inode(ia)     ubifs_jnl_write_inode(ia)      make_reservation(BASEHD) // Lock wbuf->io_mutex      ubifs_iget(ixa->i_ino)       iget_locked        find_inode_fast         __wait_on_freeing_inode(ixa)          |          iput(ib) // ib->nlink is 0, do evict          |           ubifs_evict_inode          |            ubifs_jnl_delete_inode(ib)          ↓             ubifs_jnl_write_inode     ABBA deadlock ←-----make_reservation(BASEHD)                   dispose_list // cannot be executed by prune_icache_sb                    wake_up_bit(&ixa->i_state)Fix the possible deadlock by using new inode state flag I_LRU_ISOLATINGto pin the inode in memory while inode_lru_isolate(---truncated---
 漏洞公开时间：2024-09-05 04:15:08
 漏洞创建时间：2024-09-27 02:08:14
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-45003
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45003 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2024-45003 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-45003.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2309866 | https://bugzilla.suse.com/show_bug.cgi?id=1230245 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024090450-CVE-2024-45003-3bc2@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2309866 |
| ubuntu | https://www.cve.org/CVERecord?id=CVE-2024-45003 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/linus/2a0629834cd82f05d424bbc193374f9a43d1f87d (6.11-rc4) | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://nvd.nist.gov/vuln/detail/CVE-2024-45003 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://launchpad.net/bugs/cve/CVE-2024-45003 | https://ubuntu.com/security/CVE-2024-45003 |
| ubuntu | https://security-tracker.debian.org/tracker/CVE-2024-45003 | https://ubuntu.com/security/CVE-2024-45003 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-45003 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2024-45003 |
| cve_search |  | https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 |
| cve_search |  | https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 |
| cve_search |  | https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 |
| cve_search |  | https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 |
| cve_search |  | https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 |
| cve_search |  | https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f |
| cve_search |  | https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d |
| mageia |  | http://advisories.mageia.org/MGASA-2024-0309.html |

</details>

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

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  |  | https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 |  | nvd |
|  |  | https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d |  | nvd |
|  |  | https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 |  | nvd |
|  |  | https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 |  | nvd |
|  |  | https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f |  | nvd |
|  |  | https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 |  | nvd |
|  |  | https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 |  | nvd |
| linux |  | https://git.kernel.org/linus/2a0629834cd82f05d424bbc193374f9a43d1f87d | https://git.kernel.org/linus/e50e5129f384ae282adebfb561189cdb19b81cee | ubuntu |
| linux |  | https://git.kernel.org/linus/2a0629834cd82f05d424bbc193374f9a43d1f87d | https://git.kernel.org/linus/7959cf3a7506d4a2100d5d6f37f605c2f54af488 | ubuntu |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:vfs: Don t evict inode under the inode lru traversing contextThe inode reclaiming process(See function prune_icache_sb) collects allreclaimable inodes and mark them with I_FREEING flag at first, at thattime, other processes will be stuck if they try getting these inodes(See function find_inode_fast), then the reclaiming process destroy theinodes by function dispose_list(). Some filesystems(eg. ext4 withea_inode feature, ubifs with xattr) may do inode lookup in the inodeevicting callback function, if the inode lookup is operated under theinode lru traversing context, deadlock problems may happen.Case 1: In function ext4_evict_inode(), the ea inode lookup could happen        if ea_inode feature is enabled, the lookup process will be stuckunder the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this:    PA                              PB echo 2 > /proc/sys/vm/drop_caches  shrink_slab   prune_dcache_sb   // i_reg is added into lru, lru->i_ea->i_reg   prune_icache_sb    list_lru_walk_one     inode_lru_isolate      i_ea->i_state |= I_FREEING // set inode state     inode_lru_isolate      __iget(i_reg)      spin_unlock(&i_reg->i_lock)      spin_unlock(lru_lock)                                     rm file A                                      i_reg->nlink = 0      iput(i_reg) // i_reg->nlink is 0, do evict       ext4_evict_inode        ext4_xattr_delete_inode         ext4_xattr_inode_dec_ref_all          ext4_xattr_inode_iget           ext4_iget(i_ea->i_ino)            iget_locked             find_inode_fast              __wait_on_freeing_inode(i_ea) ----→ AA deadlock    dispose_list // cannot be executed by prune_icache_sb     wake_up_bit(&i_ea->i_state)Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file        deleting process holds BASEHD s wbuf->io_mutex while getting thexattr inode, which could race with inode reclaiming process(The        reclaiming process could try locking BASEHD s wbuf->io_mutex ininode evicting function), then an ABBA deadlock problem wouldhappen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has    inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this:        PA                PB                        PC                echo 2 > /proc/sys/vm/drop_caches                 shrink_slab                  prune_dcache_sb                  // ib and ia are added into lru, lru->ixa->ib->ia                  prune_icache_sb                   list_lru_walk_one                    inode_lru_isolate                     ixa->i_state |= I_FREEING // set inode state                    inode_lru_isolate                     __iget(ib)                     spin_unlock(&ib->i_lock)                     spin_unlock(lru_lock)                                                   rm file B                                                    ib->nlink = 0 rm file A  iput(ia)   ubifs_evict_inode(ia)    ubifs_jnl_delete_inode(ia)     ubifs_jnl_write_inode(ia)      make_reservation(BASEHD) // Lock wbuf->io_mutex      ubifs_iget(ixa->i_ino)       iget_locked        find_inode_fast         __wait_on_freeing_inode(ixa)          |          iput(ib) // ib->nlink is 0, do evict          |           ubifs_evict_inode          |            ubifs_jnl_delete_inode(ib)          ↓             ubifs_jnl_write_inode     ABBA deadlock ←-----make_reservation(BASEHD)                   dispose_list // cannot be executed by prune_icache_sb                    wake_up_bit(&ixa->i_state)Fix the possible deadlock by using new inode state flag I_LRU_ISOLATINGto pin the inode in memory while inode_lru_isolate(---truncated---
 openEuler评分：
  4.7
 Vector：CVSS：3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-20.03-LTS-SP4(4.19.90):受影响
2.openEuler-22.03-LTS-SP3(5.10.0):受影响
3.openEuler-22.03-LTS-SP4(5.10.0):受影响
4.openEuler-24.03-LTS(6.6.0):受影响
5.master(6.6.0):不受影响
6.openEuler-24.03-LTS-Next(6.6.0):不受影响
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响

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

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

src-openEuler/kernel
Closed

Content Risk Flag

Comments (42)

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

Content Risk Flag

CVE-2024-45003

Comments (42)

Search

src-openEuler/kernel
Closed