CVE-2024-40904

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages<br /> <br /> The syzbot fuzzer found that the interrupt-URB completion callback in<br /> the cdc-wdm driver was taking too long, and the driver&amp;#39;s immediate<br /> resubmission of interrupt URBs with -EPROTO status combined with the<br /> dummy-hcd emulation to cause a CPU lockup:<br /> <br /> cdc_wdm 1-1:1.0: nonzero urb status received: -71<br /> cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes<br /> watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]<br /> CPU#0 Utilization every 4s during lockup:<br /> #1: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #2: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #3: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #4: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #5: 98% system, 1% softirq, 3% hardirq, 0% idle<br /> Modules linked in:<br /> irq event stamp: 73096<br /> hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline]<br /> hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994<br /> hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]<br /> hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551<br /> softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline]<br /> softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582<br /> softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588<br /> CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> <br /> Testing showed that the problem did not occur if the two error<br /> messages -- the first two lines above -- were removed; apparently adding<br /> material to the kernel log takes a surprisingly large amount of time.<br /> <br /> In any case, the best approach for preventing these lockups and to<br /> avoid spamming the log with thousands of error messages per second is<br /> to ratelimit the two dev_err() calls. Therefore we replace them with<br /> dev_err_ratelimited().