CVE-2024-53190

一、漏洞信息
 漏洞编号：[CVE-2024-53190](https://nvd.nist.gov/vuln/detail/CVE-2024-53190)
 漏洞归属组件：[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:wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresSyzkaller reported a hung task with uevent_show() on stack trace. Thatspecific issue was addressed by another commit [0], but even with thatfix applied (for example, running v6.12-rc5) we face another type of hungtask that comes from the same reproducer [1]. By investigating that, wecould narrow it to the following path:(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget anddummy_hcd infrastructure.(b) During the probe of rtl8192cu, the driver ends-up performing an efuseread procedure (which is related to EEPROM load IIUC), and here lies theissue: the function read_efuse() calls read_efuse_byte() many times, asloop iterations depending on the efuse size (in our example, 512 in total).This procedure for reading efuse bytes relies in a loop that performs anI/O read up to *10k* times in case of failures. We measured the time ofthe loop inside read_efuse_byte() alone, and in this reproducer (whichinvolves the dummy_hcd emulation layer), it takes 15 seconds each. As aconsequence, we have the driver stuck in its probe routine for big time,exposing a stack trace like below if we attempt to reboot the system, forexample:task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000Workqueue: usb_hub_wq hub_eventCall Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...]We propose hereby to drastically reduce the attempts of doing the I/Oreads in case of failures, restricted to USB devices (given thatthey re inherently slower than PCIe ones). By retrying up to 10 times(instead of 10000), we got reponsiveness in the reproducer, while seemsreasonable to believe that there s no sane USB device implementation inthe field requiring this amount of retries at every I/O read in orderto properly work. Based on that assumption, it d be good to have itbackported to stable but maybe not since driver implementation (the 10knumber comes from day 0), perhaps up to 6.x series makes sense.[0] Commit 15fffc6a5624 ( driver core: Fix uevent_show() vs driver detach race )[1] A note about that: this syzkaller report presents multiple reproducersthat differs by the type of emulated USB device. For this specific case,check the entry from 2024/08/08 06:23 in the list of crashes; the C reprois available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
 漏洞公开时间：2024-12-27 22:15:26
 漏洞创建时间：2024-12-27 22:48:51
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-53190
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/5c1b544563005a00591a3aa86ecff62ed4d11be3 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/8f3551f67991652c83469c7dd51d7b9b187b265f |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/ac064c656f105b9122bc43991a170f95f72b7a43 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c386fb76f01794f1023d01a6ec5f5c93d00acd3b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-53190 | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2024-53190 | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://git.kernel.org/stable/c/5c1b544563005a00591a3aa86ecff62ed4d11be3 | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://git.kernel.org/stable/c/8f3551f67991652c83469c7dd51d7b9b187b265f | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://git.kernel.org/stable/c/ac064c656f105b9122bc43991a170f95f72b7a43 | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://git.kernel.org/stable/c/c386fb76f01794f1023d01a6ec5f5c93d00acd3b | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://git.kernel.org/stable/c/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-53190.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2334408 | https://bugzilla.suse.com/show_bug.cgi?id=1234950 |
| redhat_bugzilla | https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000 | https://bugzilla.redhat.com/show_bug.cgi?id=2334408 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024122723-CVE-2024-53190-fdeb@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2334408 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-53190 |

</details>

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

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
| linux_kernel | 6.1.120 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c386fb76f01794f1023d01a6ec5f5c93d00acd3bFixed |  | linuxkernelcves |
| linux_kernel | 6.6.64 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8f3551f67991652c83469c7dd51d7b9b187b265fFixed |  | linuxkernelcves |
| linux_kernel | 6.11.11 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211cFixed |  | linuxkernelcves |
| linux_kernel | 6.12.2 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ac064c656f105b9122bc43991a170f95f72b7a43Fixed |  | linuxkernelcves |
| linux_kernel | 6.13-rc1 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5c1b544563005a00591a3aa86ecff62ed4d11be3Please |  | linuxkernelcves |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresSyzkaller reported a hung task with uevent_show() on stack trace. Thatspecific issue was addressed by another commit [0], but even with thatfix applied (for example, running v6.12-rc5) we face another type of hungtask that comes from the same reproducer [1]. By investigating that, wecould narrow it to the following path:(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget anddummy_hcd infrastructure.(b) During the probe of rtl8192cu, the driver ends-up performing an efuseread procedure (which is related to EEPROM load IIUC), and here lies theissue: the function read_efuse() calls read_efuse_byte() many times, asloop iterations depending on the efuse size (in our example, 512 in total).This procedure for reading efuse bytes relies in a loop that performs anI/O read up to *10k* times in case of failures. We measured the time ofthe loop inside read_efuse_byte() alone, and in this reproducer (whichinvolves the dummy_hcd emulation layer), it takes 15 seconds each. As aconsequence, we have the driver stuck in its probe routine for big time,exposing a stack trace like below if we attempt to reboot the system, forexample:task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000Workqueue: usb_hub_wq hub_eventCall Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...]We propose hereby to drastically reduce the attempts of doing the I/Oreads in case of failures, restricted to USB devices (given thatthey&#39;re inherently slower than PCIe ones). By retrying up to 10 times(instead of 10000), we got reponsiveness in the reproducer, while seemsreasonable to believe that there&#39;s no sane USB device implementation inthe field requiring this amount of retries at every I/O read in orderto properly work. Based on that assumption, it&#39;d be good to have itbackported to stable but maybe not since driver implementation (the 10knumber comes from day 0), perhaps up to 6.x series makes sense.[0] Commit 15fffc6a5624 (&#34;driver core: Fix uevent_show() vs driver detach race&#34;)[1] A note about that: this syzkaller report presents multiple reproducersthat differs by the type of emulated USB device. For this specific case,check the entry from 2024/08/08 06:23 in the list of crashes; the C reprois available at <ahref= https://syzkaller.appspot.com/text?tag=ReproC&#38;x=1521fc83980000 >https://syzkaller.appspot.com/text?tag=ReproC&#38;x=1521fc83980000</a>.The Linux kernel CVE team has assigned CVE-2024-53190 to this issue.
 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-SP1(5.10.0):受影响
3.openEuler-22.03-LTS-SP3(5.10.0):受影响
4.openEuler-22.03-LTS-SP4(5.10.0):受影响
5.openEuler-24.03-LTS(6.6.0):受影响
6.openEuler-24.03-LTS-SP1(6.6.0):受影响
7.master(6.12.33):不受影响
8.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-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-24.03-LTS-SP1(6.6.0):正常修复
6.openEuler-20.03-LTS-SP4(4.19.90):暂不修复-暂无解决方案或补丁
7.master(6.12.33):不受影响-漏洞代码不能被攻击者触发
8.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 (6)

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

Content Risk Flag

CVE-2024-53190

Comments (6)

Search

src-openEuler / kernel
Closed