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

[Danilo Krummrich]

On Mon Sep 14, 2026 at 4:30 PM CEST, 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.
>
> 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

I agree that this should be avoided.

But I also think the biggest offender really is driver_override. Specifically,
on a hot-pluggable bus a driver must be complient with the device driver
lifecycle rules and hence shouldn't break on bind/unbind. I think it would be
nice to not taint the kernel for such busses, and only taint on driver_override,
as I think we'd still want the bug reports for such cases.

But I think this is fine to leave for a follow-up.

Acked-by: Danilo Krummrich <dakr@xxxxxxxxxx>

> 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.
>
> Finally, the bind/unbind files can find real use-after-free issues with
> some drivers by forcing the process to happen virtually without having
> to rely on manual removal processes.  Those real bugs should still be
> worked on, but by adding this taint flag, developers can more easily
> determine bug reports that are actually worth looking at.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>