Re: [syzbot] [usb?] KASAN: slab-use-after-free Write in iowarrior_write_callback (2)

[Alan Stern]

On Sun, May 24, 2026 at 10:30:53AM +0200, Michal Pecio wrote:
> On Fri, 22 May 2026 13:38:40 -0700, Joseph Bursey wrote:
> > Hello, I believe I have a reproducer for this bug using a combination
> > of syz-execprog and eBPF programs.
> 
> Hi, could you check if this patch (compile tested only) fixes it?
> 
> I admit I'm not an expert on USB core, but I see nothing _reliably_
> preventing URB submissions after usb_disable_interface(), which may
> be the root cause of this bug (besides the driver sloppiness for
> which separate patches have been posted by Johan Hovold).

The general attitude has been that it isn't the core's responsibility to 
recover from bugs caused by drivers.  Rather, it is the programmers' 
responsibility to fix the bugs properly.

On the other hand, it won't hurt to add some code to the core for 
detecting and reporting buggy driver behavior, so that the programmers 
would know about it.

> My patch tries to fix it by updating ep->enabled under a spinlock
> which will be held while checking this flag on submission attempts.
> 
> Such bug is trouble not only for sloppy drivers, but also for HCDs
> which assume that no URBs exist while endpoints are being "dropped".
> Syzbot and you apparently found ways to break this assumption:
> 
> static int usb_unbind_interface(struct device *dev)
> {
> 	[...]
>         /*
>          * Terminate all URBs for this interface unless the driver
>          * supports "soft" unbinding and the device is still present.
>          */
>         if (!driver->soft_unbind || udev->state == USB_STATE_NOTATTACHED)
>                 usb_disable_interface(udev, intf, false);
> 	// no URBs should be pending on these endpoints now

Depends on whether the driver has the soft_unbind flag set and whether 
the device is still attached, obviously.

> 
>         driver->disconnect(intf);

But definitely no URBs should be pending now.

> 	// but one is observed completing concurrently now
> 
> I also suspect that more UAF in sloppy drivers is possible due to
> usb_hcd_flush_endpoint() failing to wait for pending BH givebacks.

usb_hcd_flush_endpoint() only guarantees that the HCD is finished 
dealing with any pending URBs.  It is not meant to guarantee that the 
URBs' completion handlers have run.

> It seems that dummy-hcd doesn't use HCD_BH, so this shouldn't be
> a factor here, but it could become an issue on real hardware.

Do you think it would help to provoke some exotic bugs if dummy-hcd did 
use HCD_BH?  That would be an easy change to make.

> As long as resubmission is prevented reliably, this won't affect
> HCDs, but it may cause UAF in buggy class drivers.
> 
> ---
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index b181b43a35dc..4fee30101e96 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -1958,6 +1958,15 @@ int usb_hcd_alloc_bandwidth(struct usb_device *udev,
>  	return ret;
>  }
>  
> +void usb_hcd_set_endpoint_enabled(struct usb_host_endpoint *ep, int enabled)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&hcd_urb_list_lock, flags);
> +	ep->enabled = enabled;
> +	spin_unlock_irqrestore(&hcd_urb_list_lock, flags);
> +}
> +
>  /* Disables the endpoint: synchronizes with the hcd to make sure all
>   * endpoint state is gone from hardware.  usb_hcd_flush_endpoint() must
>   * have been called previously.  Use for set_configuration, set_interface,
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 75e2bfd744a9..8d656d7e8f69 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -1358,7 +1358,7 @@ void usb_disable_endpoint(struct usb_device *dev, unsigned int epaddr,
>  			dev->ep_in[epnum] = NULL;
>  	}
>  	if (ep) {
> -		ep->enabled = 0;
> +		usb_hcd_set_endpoint_enabled(ep, 0);
>  		usb_hcd_flush_endpoint(dev, ep);
>  		if (reset_hardware)
>  			usb_hcd_disable_endpoint(dev, ep);
> @@ -1523,7 +1523,7 @@ void usb_enable_endpoint(struct usb_device *dev, struct usb_host_endpoint *ep,
>  		dev->ep_out[epnum] = ep;
>  	if (!is_out || is_control)
>  		dev->ep_in[epnum] = ep;
> -	ep->enabled = 1;
> +	usb_hcd_set_endpoint_enabled(ep, 1);
>  }

For debugging purposes you might also add a dev_warn() to 
usb_hcd_link_urb_to_ep() in the test for !urb->ep->enabled.  We can't do 
this all the time because a driver might unknowingly submit an URB just 
as the endpoint is being disabled.

Alan Stern