CVE-2024-53190— Linux kernel 安全漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞，该漏洞源于wifi:rtlwifi子系统中读取efuse时的失败重试问题。
可能的 ATT&CK 技术 1 AI
T1499 · Endpoint Denial of Service影响版本矩阵 12
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | 0c8173385e549f95cd80c3fff5aab87b4f881d8d< c386fb76f01794f1023d01a6ec5f5c93d00acd3b |
affected |
0c8173385e549f95cd80c3fff5aab87b4f881d8d< 8f3551f67991652c83469c7dd51d7b9b187b265f |
affected | ||
0c8173385e549f95cd80c3fff5aab87b4f881d8d< eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c |
affected | ||
0c8173385e549f95cd80c3fff5aab87b4f881d8d< ac064c656f105b9122bc43991a170f95f72b7a43 |
affected | ||
0c8173385e549f95cd80c3fff5aab87b4f881d8d< 5c1b544563005a00591a3aa86ecff62ed4d11be3 |
affected | ||
2.6.38 |
affected | ||
< 2.6.38 |
unaffected | ||
6.1.120≤ 6.1.* |
unaffected | ||
| … +4 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2024-53190 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
来源: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
Syzkaller reported a hung task with uevent_show() on stack trace. That
specific issue was addressed by another commit [0], but even with that
fix applied (for example, running v6.12-rc5) we face another type of hung
task that comes from the same reproducer [1]. By investigating that, we
could narrow it to the following path:
(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and
dummy_hcd infrastructure.
(b) During the probe of rtl8192cu, the driver ends-up performing an efuse
read procedure (which is related to EEPROM load IIUC), and here lies the
issue: the function read_efuse() calls read_efuse_byte() many times, as
loop iterations depending on the efuse size (in our example, 512 in total).
This procedure for reading efuse bytes relies in a loop that performs an
I/O read up to *10k* times in case of failures. We measured the time of
the loop inside read_efuse_byte() alone, and in this reproducer (which
involves the dummy_hcd emulation layer), it takes 15 seconds each. As a
consequence, 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, for
example:
task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000
Workqueue: usb_hub_wq hub_event
Call 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/O
reads in case of failures, restricted to USB devices (given that
they're inherently slower than PCIe ones). By retrying up to 10 times
(instead of 10000), we got reponsiveness in the reproducer, while seems
reasonable to believe that there's no sane USB device implementation in
the field requiring this amount of retries at every I/O read in order
to properly work. Based on that assumption, it'd be good to have it
backported to stable but maybe not since driver implementation (the 10k
number 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 reproducers
that 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 repro
is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
来源: CVE Program / CVE List V5
CVSS Information
N/A
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞，该漏洞源于wifi:rtlwifi子系统中读取efuse时的失败重试问题。
来源: 中国国家信息安全漏洞库 CNNVD
CVSS Information
N/A
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Type
N/A
来源: 中国国家信息安全漏洞库 CNNVD
受影响产品
二、漏洞 CVE-2024-53190 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2024-53190 的情报信息
请登录查看更多情报信息。
CVE-2024-53190 补丁与修复 (5)
同批安全公告 · Linux · 2024-12-27 · 共 221 条
| CVE-2024-53186 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-53209 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-56640 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-56645 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-53169 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-53179 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-53177 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-53206 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-56656 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-53176 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2024-56669 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-53224 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-53237 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56626 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56653 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56651 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56591 | 8.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56627 | 8.1 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56555 | 7.8 HIGH | Linux kernel 安全漏洞 |
| CVE-2024-56606 | 7.8 HIGH | Linux kernel 安全漏洞 |
显示前 20 条，共 221 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2024-53190
暂无评论