CVE-2024-46765

一、漏洞信息
 漏洞编号：[CVE-2024-46765](https://nvd.nist.gov/vuln/detail/CVE-2024-46765)
 漏洞归属组件：[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：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:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] <TASK>[ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] </TASK>The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---truncated---
 漏洞公开时间：2024-09-18 16:15:04
 漏洞创建时间：2024-09-18 16:59:20
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-46765
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-46765 | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2024-46765 | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| suse_bugzilla | https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| suse_bugzilla | https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3 | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| suse_bugzilla | https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-46765.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2313113 | https://bugzilla.suse.com/show_bug.cgi?id=1230807 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-46765 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2024-46765 |
| mageia |  | http://advisories.mageia.org/MGASA-2024-0316.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/2504b8405768a57a71e660dbfd5abd59f679a03f |  | nvd |
|  |  | https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3 |  | nvd |
|  |  | https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f |  | nvd |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] <TASK>[ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] </TASK>The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---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-22.03-LTS-SP1(5.10.0):受影响
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-20.03-LTS-SP4(4.19.90):不受影响
6.master(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响
8.openEuler-24.03-LTS-SP1(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.6.0):否
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-22.03-LTS-SP1(5.10.0):暂不修复-漏洞仍在分析中
3.openEuler-22.03-LTS-SP3(5.10.0):暂不修复-漏洞仍在分析中
4.openEuler-22.03-LTS-SP4(5.10.0):暂不修复-漏洞仍在分析中
5.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
6.master(6.6.0):不受影响-漏洞代码不存在
7.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不存在
8.openEuler-24.03-LTS-SP1(6.6.0):不受影响-漏洞代码不存在

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

src-openEuler/kernel
Closed

Content Risk Flag

Comments (17)

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

Content Risk Flag

CVE-2024-46765

Comments (17)

Search

src-openEuler/kernel
Closed