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.

Handle all of this by adding a new taint flag, TAINT_FORCED_BIND, which
will be set on the driver if the bind/unbind sysfs files are ever
successfully written to.  This lets kernel developers "know" that a user
is attempting to do something that is not normal, and as such, if the
kernel breaks they get to keep the shiny pieces laying around on the
floor.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Greg Kroah-Hartman (2):
      module: pull out add_taint_module() to be public
      driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers

 Documentation/admin-guide/tainted-kernels.rst | 52 ++++++++++++++-------------
 drivers/base/bus.c                            |  3 ++
 include/linux/module.h                        |  8 +++++
 include/linux/panic.h                         |  3 +-
 include/trace/events/module.h                 |  3 +-
 kernel/module/main.c                          | 13 +++++--
 kernel/panic.c                                |  5 +--
 tools/debugging/kernel-chktaint               |  8 +++++
 8 files changed, 65 insertions(+), 30 deletions(-)
---
base-commit: 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229
change-id: 20260825-bind_taint-d4077b870bc4

Best regards,
--  
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

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

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


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?

Regards,
Michal

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

On Wed, 26 Aug 2026 16:25:42 +0200, Greg Kroah-Hartman wrote:
> > 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 :(

It results in write() returning -ENODEV.

You can't bind random drivers to random devices out of the box,
you need ID overrides. And then you don't need to bind manually,
the kernel will happily select the wrong driver by default.

Authors of the recent xhci and thunderbolt patches admitted that
'driver_override' was involved in both cases.


Meanwhile, Syzbot also found a stupid write to freed memory in USB
core when HCs are unbound. You may say it doesn't matter, but:

* USB HCs are hotpluggable thunderbolt "gadgets" these days
* there were plans to alter this code so that UAF is triggered by
  hot removal of the USB device, not its parent HC

IMO the actually meaningful change would be to taint driver ID
overrides, because that's the known risky and crash-prone madness.
bind/unbind taint is noise that will be ignored.

Regards,
Michal

On Wed, Aug 26, 2026 at 05:35:49PM +0200, Michal Pecio wrote:
> On Wed, 26 Aug 2026 16:25:42 +0200, Greg Kroah-Hartman wrote:
> > > 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 :(
> 
> It results in write() returning -ENODEV.
> 
> You can't bind random drivers to random devices out of the box,
> you need ID overrides. And then you don't need to bind manually,
> the kernel will happily select the wrong driver by default.
> 
> Authors of the recent xhci and thunderbolt patches admitted that
> 'driver_override' was involved in both cases.

I'll be glad to taint if driver_override is also written to, but it's
bind() that triggers the actual action happening.  Or so the traces
show.

> Meanwhile, Syzbot also found a stupid write to freed memory in USB
> core when HCs are unbound. You may say it doesn't matter, but:
> 
> * USB HCs are hotpluggable thunderbolt "gadgets" these days

We support PCI devices being removed, but that falls under the PCI
hotplug rules/requirements, right?  Anyway, sure, we can fix those bugs
when found, but that's not the majority of what we are seeing at the
moment.  Look at all of the dumb platform drivers that are getting hit
with this on the syzbot reports...

> * there were plans to alter this code so that UAF is triggered by
>   hot removal of the USB device, not its parent HC

I don't understand what you mean by this.

> IMO the actually meaningful change would be to taint driver ID
> overrides, because that's the known risky and crash-prone madness.
> bind/unbind taint is noise that will be ignored.

it's not going to be ignored if panic_on_taint is enabled in syzbot,
which the authors have said they will do :)

thanks,

greg k-h

On Wed, 26 Aug 2026 17:44:06 +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 26, 2026 at 05:35:49PM +0200, Michal Pecio wrote:
> > You can't bind random drivers to random devices out of the box,
> > you need ID overrides. And then you don't need to bind manually,
> > the kernel will happily select the wrong driver by default.
> > 
> > Authors of the recent xhci and thunderbolt patches admitted that
> > 'driver_override' was involved in both cases.  
> 
> I'll be glad to taint if driver_override is also written to, but it's
> bind() that triggers the actual action happening.  Or so the traces
> show.

Well, I suppose probe() is the first victim to crash in such cases.

But if Syzbot is binding random drivers to random devices, the obvious
solution is to ban 'driver_override'. Using that is just cheating.

If it still manages to crash drivers by binding them to appropriate
devices then I would say it will finally be doing its job right :)

> > Meanwhile, Syzbot also found a stupid write to freed memory in USB
> > core when HCs are unbound. You may say it doesn't matter, but:
> > 
> > * USB HCs are hotpluggable thunderbolt "gadgets" these days  
> 
> We support PCI devices being removed, but that falls under the PCI
> hotplug rules/requirements, right?  Anyway, sure, we can fix those bugs
> when found, but that's not the majority of what we are seeing at the
> moment.  Look at all of the dumb platform drivers that are getting hit
> with this on the syzbot reports...
> 
> > * there were plans to alter this code so that UAF is triggered by
> >   hot removal of the USB device, not its parent HC  
> 
> I don't understand what you mean by this.

There are ideas to change some code to use per-device data instead of
per-HCD data. Coincidentally, Syzbot found that this use races with
freeing the HCD and it would also race with freeing the device, making
the UAF easier to trigger after proposed changes.

I gave it as an example of Syzbot doing something useful with 'unbind'
when it isn't wasting time on driver overrides.

Regards,
Michal