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

On 18 September 2026 18:25:38 BST, Greg Kroah-Hartman
[off-list ref] wrote:

On Fri, Sep 18, 2026 at 06:39:02PM +0200, Danilo Krummrich wrote:

quoted

On Mon Sep 14, 2026 at 4:30 PM CEST, Greg Kroah-Hartman wrote:

quoted

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

quoted

quoted

fuzzing "attack" through tools like syzbot which decided that it would
attempt to just randomly bind any driver to any type of device,

causing

quoted

quoted

loads of unneeded errors and pointless kernel patches to be generated

by

quoted

quoted

unsuspecting new developers.

Handle all of this by adding a new taint flag, TAINT_FORCED_BIND,

which

quoted

quoted

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,

quoted

quoted

as many times crashes/oops/warnings/failures happen within the

callback,

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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,

quoted

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

quoted

nice to not taint the kernel for such busses, and only taint on

driver_override,

quoted

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.

Yeah, let's see how this goes, thanks for the review!

Famous last words :) 

(I see no regression but AI finds mysteries)

greg k-h

--- Thanks!

https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/ (local)