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

On Tue, Sep 22, 2026 at 11:04:46PM +0200, Armin Wolf wrote:

Am 22.09.26 um 15:40 schrieb David Lechner:

quoted

On 9/22/26 2:39 AM, Uwe Kleine-König wrote:

quoted

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

I fully agree with this, drivers should correctly implement the lifecycle model
and not just break when being unbound at a improper time. Drivers suffering from
this can easily break this way when unloading the associated kernel module, so this
taint is no solution.

quoted

In the IIO subsystem, unbind/rebind is the de-facto way to reset a wedged
chip.

A few examples where other reset methods were reject in favor of unbind/bind:

https://lore.kernel.org/linux-iio/20240727160216.2488ed29@jic23-huawei/ (local)

	This needs documenting as it's custom ABI. Note that we don't often
	accept custom ABI. Particularly not a hook that seems to reset the
	device. If you want to do that, unbind and rebind the whole drive[r]
	so we are in a known state etc.

https://lore.kernel.org/linux-iio/20240720163440.03c713dc@jic23-huawei/ (local)

	Firstly as stated below, we don't provide interfaces for this
	because it's a heavy weight process that is most of the effort of
	unbinding and rebinding the driver. So if you need to reset, do that.

https://lore.kernel.org/linux-iio/20250505200609.54756520@jic23-huawei/ (local)

	The solution is to run it once at driver bind. Similar to reset
	below, if the usecase needs to re do it then unbinding and rebinding
	the driver reflects the fact we are taking it effectively offline
	for a while.

I also consider bind/unbind to be an official API to interact with devices,
so i want to use them in the future with the WMI subsystem.

AFAIK the underlying reason for this series is that some drivers break when
being bound to unsupported devices. However IMHO drivers should verify that
they support a given device inside their .probe callback, and the associated
bus should only match devices with drivers that explicitly claim support for
those devices (ignoring driver_override).

Can we get some example bugs uncovered this way?

There is a related set of mail threads, that however are not the trigger
for Greg's effort. 

Initially I suggested to protect the pwm-tegra driver from attaching
to unexpected devices via a check in .probe():

   https://lore.kernel.org/linux-pwm/ed943d9be3b785514e0f65a5b8c13a78aba7a090.1789741839.git.u.kleine-koenig@baylibre.com/ (local)

Thierry suggested a dedicated flag in struct device_driver instead
allowing to opt out of the driver_override mechanism:

   https://lore.kernel.org/linux-pwm/20260922-driver-override-opt-out-v1-0-58c35ded3b83@nvidia.com/ (local)

I think Greg was motivated by syzcaller triggering various exceptions
using driver_override.

So my opinion on the right way forward is:

 - Given that there are only very few drivers that are supposed to be
   used for a driver override, there should be an opt-in (instead of the
   opt-out that Thierry suggested).

 - The changes from this thread (i.e. make usage of bind/unbind result
   in a taint) should be dropped. I wrote earlier that I'm ok with a
   taint for a usage of driver_override, but with the previous item
   implemented, I don't think that is necessary.

Best regards
Uwe