CVE-2024-56592

一、漏洞信息
 漏洞编号：[CVE-2024-56592](https://nvd.nist.gov/vuln/detail/CVE-2024-56592)
 漏洞归属组件：[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：5.5 Medium
  Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning:  =============================  [ BUG: Invalid wait context ]  6.11.0-rc4+ #49 Not tainted  -----------------------------  test_maps/4881 is trying to lock:  ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70  other info that might help us debug this:  context-{5:5}  2 locks held by test_maps/4881:   #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270   #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80  stack backtrace:  CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...  Call Trace:   <TASK>   dump_stack_lvl+0x6e/0xb0   dump_stack+0x10/0x20   __lock_acquire+0x73e/0x36c0   lock_acquire+0x182/0x450   _raw_spin_lock_irqsave+0x43/0x70   bpf_map_free_id.part.0+0x21/0x70   bpf_map_put+0xcf/0x110   bpf_map_fd_put_ptr+0x9a/0xb0   free_htab_elem+0x69/0xe0   htab_map_update_elem+0x50f/0xa80   bpf_fd_htab_map_update_elem+0x131/0x270   htab_map_update_elem+0x50f/0xa80   bpf_fd_htab_map_update_elem+0x131/0x270   bpf_map_update_value+0x266/0x380   __sys_bpf+0x21bb/0x36b0   __x64_sys_bpf+0x45/0x60   x64_sys_call+0x1b2a/0x20d0   do_syscall_64+0x5d/0x100   entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab s lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock s type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn t support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn t have the problem, so keptit as---truncated---
 漏洞公开时间：2024-12-27 23:15:18
 漏洞创建时间：2024-12-27 23:59:01
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-56592
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/10e8a2dec9ff1b81de8e892b0850924038adbc6d |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a50b4aa3007e63a590d501341f304676ebc74b3b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78 |  |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024122700-CVE-2024-56592-d4b2@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2334494 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-56592 |

</details>

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

无
</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning:  =============================  [ BUG: Invalid wait context ]  6.11.0-rc4+ #49 Not tainted  -----------------------------  test_maps/4881 is trying to lock:  ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70  other info that might help us debug this:  context-{5:5}  2 locks held by test_maps/4881:   #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270   #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80  stack backtrace:  CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...  Call Trace:   <TASK>   dump_stack_lvl+0x6e/0xb0   dump_stack+0x10/0x20   __lock_acquire+0x73e/0x36c0   lock_acquire+0x182/0x450   _raw_spin_lock_irqsave+0x43/0x70   bpf_map_free_id.part.0+0x21/0x70   bpf_map_put+0xcf/0x110   bpf_map_fd_put_ptr+0x9a/0xb0   free_htab_elem+0x69/0xe0   htab_map_update_elem+0x50f/0xa80   bpf_fd_htab_map_update_elem+0x131/0x270   htab_map_update_elem+0x50f/0xa80   bpf_fd_htab_map_update_elem+0x131/0x270   bpf_map_update_value+0x266/0x380   __sys_bpf+0x21bb/0x36b0   __x64_sys_bpf+0x45/0x60   x64_sys_call+0x1b2a/0x20d0   do_syscall_64+0x5d/0x100   entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab s lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock s type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn t support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn t have the problem, so keptit as---truncated---
 openEuler评分：
  5.5
 Vector：CVSS：3.0/AV:L/AC:L/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.openEuler-24.03-LTS-SP1(6.6.0):受影响
6.master(6.12.33):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响

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

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

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

src-openEuler/kernel
Closed

Content Risk Flag

Comments (8)

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

Content Risk Flag

CVE-2024-56592

Comments (8)

Search

src-openEuler/kernel
Closed