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

["Uwe Kleine-König" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]

On Fri, Sep 18, 2026 at 06:39:02PM +0200, Danilo Krummrich wrote:
> 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.

I fully agree. I'm fine and support tainting on driver_override, but
bind/unbind are used occasionally in my bubble and I consider drivers
not handling that properly buggy.

So please let's do

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index c51ad96d4de4..ce8fb14ea19a 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -242,7 +242,6 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf,
 
 	dev = bus_find_device_by_name(bus, NULL, buf);
 	if (dev && dev->driver == drv) {
-		add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
 		device_driver_detach(dev);
 		err = count;
 	}
@@ -266,7 +265,6 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf,
 
 	dev = bus_find_device_by_name(bus, NULL, buf);
 	if (dev && driver_match_device(drv, dev)) {
-		add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
 		err = device_driver_attach(drv, dev);
 		if (!err) {
 			/* success */
@@ -513,6 +511,7 @@ static ssize_t driver_override_store(struct device *dev,
 {
 	int ret;
 
+	add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
 	ret = __device_set_driver_override(dev, buf, count);
 	if (ret)
 		return ret;

(plus the needed documentation adaptions and maybe a rename
s/TAINT_FORCED_BIND/TAINT_DRIVER_OVERRIDE/).

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]