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

Hello Greg,

On Wed, Sep 23, 2026 at 11:27:11AM +0200, Greg Kroah-Hartman wrote:
> 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.
> 
> It's a "solution" in that it tells the developer "hey, the user did
> something odd and unsupported".  rmmod is also not a normal operation,
> there's no requirement that it actually work as it's usually a "best
> effort" type of thing.
> 
> > > 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.
> 
> Why?
> 
> > 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).
> 
> No, drivers should NOT have to do that in their .probe() function,
> that's what we moved away from decades ago!  The match function should
> handle all of that for you, otherwise it's contant duplication
> everywhere that is unneeded.

Well then you have to accept that root can provoke a null pointer
exception (e.g. by forcing the pwm-tegra driver on a device) because at
least with today's platform bus match function such a match is ok.
 
> Please, learn from our history, don't make the same mistakes.
> 
> Now I might be convinced that driver_override is the way to go here, but
> it still feels really odd as again, bind/unbind was created as a driver
> debugging option only, it should NOT be a normal operation that any user
> should rely on.  The driver should "just work" properly instead, without
> requiring manual bind work, as that's not a good model at all.

I agree in principle, but (in my case wifi) drivers are buggy sometimes
(due to missing documentation and/or engineering effort) and being able
to rebind the driver instead of rebooting to get a working device again
is very useful.

So yes, theoretically bind/unbind isn't needed, but theory and practise
differ in practise.

OK, as a compromise: Let's keep the taint (after all that's not
destroying any functionality, just adding a hint for bug reports),
and make driver_override opt-in, which should close an attack surface
(mostly for fuzzers?) and so reduce the amount of bug reports instead of
marking a part of them as tainted only.

Best regards
Uwe

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