Re: [PATCH v3 0/2] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Sep 04, 2026 at 09:46:59PM +0200, Armin Wolf wrote:
> 
> Am 04.09.26 um 07:10 schrieb Greg Kroah-Hartman:
> > 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
> > 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.
> > 
> > The flag is 'Y' which was unused, and can remembered as the user is
> > "yeeting" the device being operated on here (thrown with force without
> > regard for the thing being thrown).
> > 
> > Note, the taint flag gets set _BEFORE_ the bind/unbind callback happens,
> > as many times crashes/oops/warnings/failures happen within the callback,
> > and the taint flag needs to be there to show what was being attempted.
> > If it were to be set after the callback happens, the oops report would
> > not properly reflect what foolishness was being attempted.
> > 
> > Fuzzing tools like syzbot, that doesn't have hand-crafted rules to keep
> > the tool from hitting bind/unbind, should be run with panic_on_taint
> > enabled so that they fall over and don't continue on, thinking that they
> > actually found a real issue.
> > 
> > Userspace operations that rely on the bind/unbind files to work around
> > the lack of will to upgrade a kernel image to a newer version with
> > proper support for new devices, or the lack of will to submit valid
> > device ids to driver authors, will still work properly, but now the
> > kernel will be flagged in a way that will show that perhaps those users
> > should reconsider their behavior and work to have the drivers properly
> > support these devices in a "native" manner.
> 
> What about users that use driver_override together with vfio-pci? AFAIK
> they still need to write to bind/unbind.

As I state above, that is an abuse of this api.

> Also i always liked the fact that the bind/unbind attributes make it very
> easy in creating generic drivers. In fact, i am intending to use this feature
> in order to add netlink support to the ACPI-WMI subsystem in the future.
> I am planning to realize this thru a generic WMI driver that has to be manually
> bound to a given WMI device to make it available over netlink, so having
> users be able to write bind/unbind without potentially triggering a kernel panic
> would be very nice.

It's a taint flag being set, not a panic, showing developers that "hey,
the user just did something odd here, ask them about it when handling
this bug report."

> Additionally, writing into the bind attribute still checks if the driver and the
> device match:
> 
> /*
>  * Manually attach a device to a driver.
>  * Note: the driver must want to bind to the device,
>  * it is not possible to override the driver's id table.
>  */
> static ssize_t bind_store(struct device_driver *drv, const char *buf, size_t count)
> 
> Because of this i would suggest that the taint (if at all) be added to the
> driver_override attribute instead, because only with this attribute users can bind
> random drivers to truly random devices.

I had thought of that, but the force removal of drivers from devices
wouldn't show up this way, which is one of the things that we do want to
warn developers about.

And, if we just did the driver_override taint, it would allow those
drivers who claim to be "generic" like you are referring to, to keep
"getting away with that" when it's obviously not true that they can
handle any device for that bus, otherwise it would have automatically
bound to it already (and no manual intervention would be needed.)

By keeping the manual configuration of bind, you are forcing userspace
to manually do work, while still a possible thing to do, now at least a
developer who gets a bug report will _know_ it happened, which is why
the taint flag is there.

Does that make a bit more sense?

thanks,

greg k-h