Re: [PATCH v5] usb: xhci: Fix use-after-free race in xhci_stop_device()

[Michal Pecio <michal.pecio@gmail.com>]

On Wed, 4 Nov 2026 23:54:39 -0500, Alan Stern wrote:
> > What I find more disturbing is the existing protection from this
> > race added by 88716a93766b - it looks like core was triggering this
> > too.  
> 
> I don't know anything about it.  That commit only touches xhci-hub.c, 
> not usbcore.

Well, it looked like core was calling hcd->bus_suspend() before
disconnection has completed.

But I just found that xhci-hcd had a bug where hcd->free_dev() would
return before disconnection has fully completed, which can obviously
trick core into doing the above. Now fixed by 7faac1953ed1.

> There should never be any outstanding URBs on suspended ports.  If
> you have any examples, they need to be fixed.

There was a report of some HID driver leaving a pending URB on ep0.
Core blocks and flushes other endpoints, but ep0 is still needed by
device driver's suspend() call IIRC, so it only gets flushed after
the port is put in suspend. I wrote a patch which reliably triggers
ep0 unlink on a suspended port in this manner.

Reporter's HC wasn't expecting this and failed to perform the unlink.

> The core relies on drivers to unlink outstanding URBs and not submit
> any new ones after they have been told that their devices are going
> into suspend.

That's a little weak. The reporter got an LLM to patch the offending
driver, the LLM claimed that other similar drivers have similar bugs,
business as usual. IDK if they have been fixed.

Also, core ignores suspend() routines returning errors during system
sleep transitions. I'm not sure if drivers are *allowed* to return
-EBUSY in those cases, like they do to prevent autosuspend, but it's
at least another opportunity for bugs in drivers to cause issues.

> I suppose we could check that there are no errant URBs still in
> progress just before putting the port into suspend, but is this
> really necessary?

It's already being done, looks like those drivers aren't *actually*
trusted very much. But there is the ep0 loophole.

Regards,
Michal