[PATCH] hid: usbhid: fix deadlock in hid_post_reset()

[PATCH] hid: usbhid: fix deadlock in hid_post_reset()

[Oliver Neukum]

You can build a USB device that includes a HID component
and a storage or UAS component. The components can be reset
only together. That means that hid_pre_reset() and hid_post_reset()
are in the block IO error handling. Hence no memory allocation
used in them may do block IO because the IO can deadlock
on the mutex held while resetting a device and calling the
interface drivers.
Use GFP_NOIO for all allocations in them.

Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/hid/usbhid/hid-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ddd5d77fb5a5..fd3e1aedc5cb 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1552,7 +1552,7 @@ static int hid_post_reset(struct usb_interface *intf)
 	 * configuration descriptors passed, we already know that
 	 * the size of the HID report descriptor has not changed.
 	 */
-	rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
+	rdesc = kmalloc(hid->dev_rsize, GFP_NOIO);
 	if (!rdesc)
 		return -ENOMEM;
 
-- 
2.53.0

Re: [PATCH] hid: usbhid: fix deadlock in hid_post_reset()

[Jiri Kosina]

On Tue, 24 Mar 2026, Oliver Neukum wrote:

> You can build a USB device that includes a HID component
> and a storage or UAS component. The components can be reset
> only together. That means that hid_pre_reset() and hid_post_reset()
> are in the block IO error handling. Hence no memory allocation
> used in them may do block IO because the IO can deadlock
> on the mutex held while resetting a device and calling the
> interface drivers.
> Use GFP_NOIO for all allocations in them.
> 
> Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset")
> Signed-off-by: Oliver Neukum <oneukum@suse.com>

Thanks Oliver.

Did you find this just by code inspection, or was this reported with a 
real device?

Thanks,

-- 
Jiri Kosina
SUSE Labs