CVE-2024-53190

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures<br /> <br /> Syzkaller reported a hung task with uevent_show() on stack trace. That<br /> specific issue was addressed by another commit [0], but even with that<br /> fix applied (for example, running v6.12-rc5) we face another type of hung<br /> task that comes from the same reproducer [1]. By investigating that, we<br /> could narrow it to the following path:<br /> <br /> (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and<br /> dummy_hcd infrastructure.<br /> <br /> (b) During the probe of rtl8192cu, the driver ends-up performing an efuse<br /> read procedure (which is related to EEPROM load IIUC), and here lies the<br /> issue: the function read_efuse() calls read_efuse_byte() many times, as<br /> loop iterations depending on the efuse size (in our example, 512 in total).<br /> <br /> This procedure for reading efuse bytes relies in a loop that performs an<br /> I/O read up to *10k* times in case of failures. We measured the time of<br /> the loop inside read_efuse_byte() alone, and in this reproducer (which<br /> involves the dummy_hcd emulation layer), it takes 15 seconds each. As a<br /> consequence, we have the driver stuck in its probe routine for big time,<br /> exposing a stack trace like below if we attempt to reboot the system, for<br /> example:<br /> <br /> task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __schedule+0xe22/0xeb6<br /> schedule_timeout+0xe7/0x132<br /> __wait_for_common+0xb5/0x12e<br /> usb_start_wait_urb+0xc5/0x1ef<br /> ? usb_alloc_urb+0x95/0xa4<br /> usb_control_msg+0xff/0x184<br /> _usbctrl_vendorreq_sync+0xa0/0x161<br /> _usb_read_sync+0xb3/0xc5<br /> read_efuse_byte+0x13c/0x146<br /> read_efuse+0x351/0x5f0<br /> efuse_read_all_map+0x42/0x52<br /> rtl_efuse_shadow_map_update+0x60/0xef<br /> rtl_get_hwinfo+0x5d/0x1c2<br /> rtl92cu_read_eeprom_info+0x10a/0x8d5<br /> ? rtl92c_read_chip_version+0x14f/0x17e<br /> rtl_usb_probe+0x323/0x851<br /> usb_probe_interface+0x278/0x34b<br /> really_probe+0x202/0x4a4<br /> __driver_probe_device+0x166/0x1b2<br /> driver_probe_device+0x2f/0xd8<br /> [...]<br /> <br /> We propose hereby to drastically reduce the attempts of doing the I/O<br /> reads in case of failures, restricted to USB devices (given that<br /> they&amp;#39;re inherently slower than PCIe ones). By retrying up to 10 times<br /> (instead of 10000), we got reponsiveness in the reproducer, while seems<br /> reasonable to believe that there&amp;#39;s no sane USB device implementation in<br /> the field requiring this amount of retries at every I/O read in order<br /> to properly work. Based on that assumption, it&amp;#39;d be good to have it<br /> backported to stable but maybe not since driver implementation (the 10k<br /> number comes from day 0), perhaps up to 6.x series makes sense.<br /> <br /> [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")<br /> <br /> [1] A note about that: this syzkaller report presents multiple reproducers<br /> that differs by the type of emulated USB device. For this specific case,<br /> check the entry from 2024/08/08 06:23 in the list of crashes; the C repro<br /> is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.