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

[Alan Stern <stern@rowland.harvard.edu>]

On Wed, Nov 04, 2026 at 11:56:37AM +0800, YuanZhe Liu wrote:
> The port suspend is a hub class SET_FEATURE(PORT_SUSPEND) sent from
> userspace through usbfs, and the teardown is userspace releasing the
> hub driver interface, which quiesces the hub and disconnects every
> child under it.  Neither side takes a per-device reference, and the
> usbfs control request is not serialized against the hub driver being
> unbound.  That is also why xhci_bus_suspend() 100 ms after a disconnect
> looks fine: this is a different entry into xhci_stop_device().
> 
> CLEAR_FEATURE(PORT_SUSPEND) is the resume direction: in
> xhci_hub_control() it ends in xhci_ring_device(), so it cannot produce
> this trace.

> The patch makes xhci_stop_device() re-read xhci->devs[] and the "device
> is going away" marker under xhci->lock, and give up with -ENODEV
> instead of touching a device that xhci_free_dev() has already detached.
> For that check to mean anything, xhci_free_dev() has to clear
> virt_dev->udev under the same lock, which is the second hunk.
> 
> If you think the mutual exclusion belongs higher up instead - do not
> let usbfs suspend a port while the hub is being unbound - I am happy to
> work on that; from your message it sounds like you would prefer the fix
> there.

Don't know about Michal, but _I_ think the problem should be solved 
higher up in the stack.  It sounds like the sort of race that could 
affect any HCD, not just xhci-hcd.

Alan Stern