Re: RFC: Prevent long uninterruptible waits in usbcore

[Greg KH <gregkh@linuxfoundation.org>]

On Sun, Feb 08, 2026 at 09:33:02PM -0500, Alan Stern wrote:
> I'm asking for comments on the patch below.  The problem it fixes is 
> that usb_start_wait_urb(), which is used by utility routines like 
> usb_bulk_msg() and usb_control_msg(), can have arbitrarily long 
> uninterruptible waits.  And of course this can trigger the kernel's 
> warning about a hung task.
> 
> Normally this isn't a problem, because drivers calling these routines 
> generally specify timeouts on the order of 10 seconds or less.  In the 
> particular case found by syzbot, however, the usbtmc driver uses a 
> timeout value that it gets from an ioctl with no checking for 
> excessively large numbers (see usbtmc_ioctl_set_timeout()).  We could 
> change this one function, but what about other drivers?  There should be 
> a single policy on how we handle these things.
> 
> Now, I suppose the reason that the usb_start_wait_urb() uses 
> uninterruptible waits is that drivers don't want their calls to be 
> interrupted and aren't prepared for that possibility.  But we also don't 
> want them to tie up a kernel thread in a ridiculously long 
> uninterruptible wait state.
> 
> I thought that a reasonable compromise would be to keep the 
> uninterruptible waits for timeout periods less than 60 seconds (somewhat 
> arbitrary, but hopefully short enough not to trigger the hung-task 
> detector) and make them interruptible if the timeout is longer.  The 
> idea is that long USB timeouts don't normally arise in the kernel, so 
> they are probably caused by a user request (or a bad device), which 
> would mean that interrupting them wouldn't be such a bad thing.
> 
> Any other ideas or thoughts about this?

Having an upper-bound on this is a good idea, and also the usbtmc driver
should also be fixed to just reject extra-long delays in that ioctl as
that's a user-visable way to stall a cpu.

So no objection from me with this patch.

thanks,

greg k-h