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: 6415 bytes --]

On Tue, Sep 22, 2026 at 11:04:46PM +0200, Armin Wolf wrote:
> Am 22.09.26 um 15:40 schrieb David Lechner:
> 
> > On 9/22/26 2:39 AM, Uwe Kleine-König wrote:
> > > 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.
> 
> 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.
> 
> > 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/
> > 
> > 	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/
> > 
> > 	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/
> > 
> > 	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/

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/

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

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