CVE-2022-49936

In the Linux kernel, the following vulnerability has been resolved:

USB: core: Prevent nested device-reset calls

Automatic kernel fuzzing revealed a recursive locking violation in usb-storage:

============================================ WARNING: possible recursive locking detected

5.18.0 #3 Not tainted

kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&usinterfacekey[i]){+.+.}-{3:3}, at: usbstorpre_reset+0x35/0x40 drivers/usb/storage/usb.c:230

but task is already holding lock: ffff888018638db8 (&usinterfacekey[i]){+.+.}-{3:3}, at: usbstorpre_reset+0x35/0x40 drivers/usb/storage/usb.c:230

...

stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usbhubwq hub_event Call Trace: <TASK> __dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 printdeadlockbug kernel/locking/lockdep.c:2988 [inline] checkdeadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lockacquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lockacquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutexlockcommon kernel/locking/mutex.c:603 [inline] __mutexlock+0x14f/0x1610 kernel/locking/mutex.c:747 usbstorprereset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_resetdevice+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xudevremove+0x21a/0x270 drivers/staging/rtl8712/usbintf.c:622 usbunbindinterface+0x1bd/0x890 drivers/usb/core/driver.c:458 deviceremove drivers/base/dd.c:545 [inline] deviceremove+0x11f/0x170 drivers/base/dd.c:537 _devicereleasedriver drivers/base/dd.c:1222 [inline] devicereleasedriverinternal+0x1a7/0x2f0 drivers/base/dd.c:1248 usbdriverreleaseinterface+0x102/0x180 drivers/usb/core/driver.c:627 usbforcedunbindintf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usbresetdevice+0x39b/0x9a0 drivers/usb/core/hub.c:6114

This turned out not to be an error in usb-storage but rather a nested device reset attempt. That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have prereset or postreset callbacks), its ->remove routine called usbresetdevice() -- thus nesting one reset call within another.

Performing a reset as part of disconnect processing is a questionable practice at best. However, the bug report points out that the USB core does not have any protection against nested resets. Adding a resetinprogress flag and testing it will prevent such errors in the future.