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

[Bradley Morgan <brads@mainlining.org>]

On 18 September 2026 18:25:38 BST, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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.
>
>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/