CVE-2025-68194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imon: make send_packet() more robust<br /> <br /> syzbot is reporting that imon has three problems which result in<br /> hung tasks due to forever holding device lock [1].<br /> <br /> First problem is that when usb_rx_callback_intf0() once got -EPROTO error<br /> after ictx-&gt;dev_present_intf0 became true, usb_rx_callback_intf0()<br /> resubmits urb after printk(), and resubmitted urb causes<br /> usb_rx_callback_intf0() to again get -EPROTO error. This results in<br /> printk() flooding (RCU stalls).<br /> <br /> Alan Stern commented [2] that<br /> <br /> In theory it&amp;#39;s okay to resubmit _if_ the driver has a robust<br /> error-recovery scheme (such as giving up after some fixed limit on the<br /> number of errors or after some fixed time has elapsed, perhaps with a<br /> time delay to prevent a flood of errors). Most drivers don&amp;#39;t bother to<br /> do this; they simply give up right away. This makes them more<br /> vulnerable to short-term noise interference during USB transfers, but in<br /> reality such interference is quite rare. There&amp;#39;s nothing really wrong<br /> with giving up right away.<br /> <br /> but imon has a poor error-recovery scheme which just retries forever;<br /> this behavior should be fixed.<br /> <br /> Since I&amp;#39;m not sure whether it is safe for imon users to give up upon any<br /> error code, this patch takes care of only union of error codes chosen from<br /> modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.<br /> ir_toy, mceusb and igorplugusb).<br /> <br /> Second problem is that when usb_rx_callback_intf0() once got -EPROTO error<br /> before ictx-&gt;dev_present_intf0 becomes true, usb_rx_callback_intf0() always<br /> resubmits urb due to commit 8791d63af0cf ("[media] imon: don&amp;#39;t wedge<br /> hardware after early callbacks"). Move the ictx-&gt;dev_present_intf0 test<br /> introduced by commit 6f6b90c9231a ("[media] imon: don&amp;#39;t parse scancodes<br /> until intf configured") to immediately before imon_incoming_packet(), or<br /> the first problem explained above happens without printk() flooding (i.e.<br /> hung task).<br /> <br /> Third problem is that when usb_rx_callback_intf0() is not called for some<br /> reason (e.g. flaky hardware; the reproducer for this problem sometimes<br /> prevents usb_rx_callback_intf0() from being called),<br /> wait_for_completion_interruptible() in send_packet() never returns (i.e.<br /> hung task). As a workaround for such situation, change send_packet() to<br /> wait for completion with timeout of 10 seconds.