wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
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+0
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.1.120, 6.11.11, 6.12.2, 6.6.64
- CVEs
- CVE-2024-53190
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 5 Nov 2026, 01:59 UTC · Revision 1
Source evidence
wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
core-osv · Original sourcePublished 27 Dec 2024, 13:49 UTC
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+0
osv:CVE-2024-53190
Kernel
Fixed versions: 6.1.120, 6.6.64, 6.11.11, 6.12.2
Complete source record
{
"id": "2c42b8d0a4fa110032b8dbaa39af1c0b66eceac49df4655eaf816bbe4911dbc7",
"url": "https://osv.dev/vulnerability/CVE-2024-53190",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures",
"summary": "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+0",
"evidence": "osv:CVE-2024-53190",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.1.120",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.64",
"evidence": "/affected/1/ranges"
},
{
"value": "6.11.11",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.2",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "CVE-2024-53190",
"aliases": [
"CVE-2024-53190"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "0c8173385e549f95cd80c3fff5aab87b4f881d8d"
},
{
"fixed": "c386fb76f01794f1023d01a6ec5f5c93d00acd3b"
},
{
"fixed": "8f3551f67991652c83469c7dd51d7b9b187b265f"
},
{
"fixed": "eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c"
},
{
"fixed": "ac064c656f105b9122bc43991a170f95f72b7a43"
},
{
"fixed": "5c1b544563005a00591a3aa86ecff62ed4d11be3"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-53190.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "2.6.38"
},
{
"fixed": "6.1.120"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.64"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.11.11"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.12.0"
},
{
"fixed": "6.12.2"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-53190.json"
}
}
],
"modified": "2026-10-28T02:30:41.987825334Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/5c1b544563005a00591a3aa86ecff62ed4d11be3",
"https://git.kernel.org/stable/c/8f3551f67991652c83469c7dd51d7b9b187b265f",
"https://git.kernel.org/stable/c/ac064c656f105b9122bc43991a170f95f72b7a43",
"https://git.kernel.org/stable/c/c386fb76f01794f1023d01a6ec5f5c93d00acd3b",
"https://git.kernel.org/stable/c/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c",
"https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53190.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-53190",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53190.json"
}
},
"related_cves": [
{
"value": "CVE-2024-53190",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 509290,
"published_at": "2024-12-27T13:49:32.691+00:00"
}