On Wed, Aug 26, 2026 at 03:33:11PM +0200, Michal Pecio wrote:
> On Wed, 26 Aug 2026 11:19:31 +0200, Greg Kroah-Hartman wrote:
> > The ability to add and remove devices from a driver through the sysfs
> > "bind" and "unbind" files was created all those decades ago as a way
> > that kernel developers can iterate faster, and provide a debugging way
> > for users to attempt to add a new device to a driver without having to
> > rebuild their kernel.
> > 
> > This api over the years has been abused and recently come under a major
> > fuzzing "attack" through tools like syzbot which decided that it would
> > attempt to just randomly bind any driver to any type of device, causing
> > loads of unneeded errors and pointless kernel patches to be generated by
> > unsuspecting new developers.
> 
> Hi Greg,
> 
> I think you confused 'bind' / 'unbind' with the likes of 'new_id' and
> 'driver_override'. Try binding xhci_hcd to NVMe, you won't get far.

It seems to result in a failure report that people keep sending random
patches for :(

> FYI, besides being footguns, the latter are apparently used to assign
> any random PCI device to some VM drivers for passthrough or whatnot.

Which should be fixed.

> The former hardly are footguns and have further common uses, such as
> removing kernel drivers to make VM / USBFS work or "turn it off and on
> again" when a driver doesn't implement recovery. I've seen a published
> script which does this automatically when xhci goes belly up...

And we should fix the root cause here.

> I am also not convinced that fuzzing 'unbind' alone is a bad thing.
> How is that different from 'rmmod' or pulling out a USB-C plug, which
> may have a bunch of USB *and* PCI devices behind it, mid-operation?

rmmod too is something that is never guaranteed to work, and is for
developers.  "luckily" syzbot doesn't seem to want to do that just yet
:)

This is to stem the tide of foolish patches where people/syzbot is
attempting to bind any random device to any random driver and then
reporting a "bug" for when things go wrong.  It is also here to mark a
kernel as "hey, something was manually overridden" if a normal user does
this and then attempts to ask for support for us.  Both are good things
for developers to know about.

thanks,

greg k-h

Reply via email to