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

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

On Sun, 24 May 2026 10:45:39 -0400, Alan Stern wrote:
> 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.

Well, there is also the attitude that core doesn't do crazy stuff like
removing endpoints and resetting or suspending devices with URBs on
them, so HCDs don't do much to handle such anomalies.

https://lore.kernel.org/linux-usb/5f7a69d7-87fc-436b-a3c9-b9d4fc1a5c17@rowland.harvard.edu/

Combine the two and a buggy driver might take down the whole bus.
I'm inclined to see the existence of these usb_disable_endpoint() calls
in various places as an admission that USB subsystem has never really
placed much faith on all those class drivers. Maybe rightly so ;)

I noticed commit f9a5b4f58b28 ("usb: Avoid use-after-free by flushing
endpoints early in usb_set_interface()"), which sounds a little scary.

> 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.

Current situation is that core removes some 99.9% of all URBs before
calling disconnect() or performing aforementioned HCD operations, so
recovery paths (if any) aren't getting much testing and one could write
a successfull driver without even knowing that usb_unlink_urb() exists.

But the remaining 0.1% of time things like this syzbot report happen,
and back when the number was more like 90%, the remaining 10% was
apparently quite exciting on the xhci-hcd side too:

https://lore.kernel.org/linux-usb/20180721105509.hjocon6ngk2liwo4@debian/T/

If the URB elimination ratio could be brought up to 100% with a small
tweak I think it's an attractive prospect, hence

> > My patch tries to fix it by updating ep->enabled under a spinlock
> > which will be held while checking this flag on submission attempts.


> > 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.

Fair enough.
 
> > 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.

Not sure, besides the obvious possibility of a BH completion being
missed by usb_hcd_flush_endpoint() and running after disconnect().
Also not sure if syzbot would catch those cases if BH is enabled.

Regards,
Michal