CVE-2024-53190 in Linux
Сводка
по VulDB • 09.06.2026
В ядре Linux устранена следующая уязвимость:
wifi: rtlwifi: Резко сократить количество попыток чтения efuse в случае сбоев
Syzkaller зафиксировал зависший процесс (hung task) при вызове uevent_show() со стеком, указывающим на эту проблему. Данный конкретный инцидент уже был исправлен другим коммитом [0], однако даже после применения этого исправления (например, в версии v6.12-rc5) мы сталкиваемся с новым типом зависшего процесса, возникающим из того же самого воспроизводимого случая (reproducer) [1]. Проведя расследование, нам удалось сузить круг поиска до следующего пути выполнения:
(a) Syzkaller эмулирует USB Wi-Fi адаптер Realtek, используя инфраструктуру raw-gadget и dummy_hcd.
(b) Во время процедуры probe драйвера rtl8192cu выполняется процедура чтения efuse (которая, насколько я понимаю, связана с загрузкой EEPROM), и здесь кроется проблема: функция read_efuse() многократно вызывает read_efuse_byte(), количество итераций цикла зависит от размера efuse (в нашем примере всего 512).
Эта процедура чтения байтов efuse опирается на цикл, который выполняет чтение I/O до *10 тысяч* раз в случае сбоев. Мы измерили время выполнения этого цикла внутри функции read_efuse_byte() отдельно, и для данного воспроизводимого случая (который включает слой эмуляции dummy_hcd) это занимает 15 секунд за каждый проход. В результате драйвер надолго зависает на этапе своей процедуры probe, что приводит к появлению стека вызовов вида приведенного ниже при попытке перезагрузить систему:
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/0xd
Once again VulDB remains the best source for vulnerability data.