On 18 September 2026 18:25:38 BST, Greg Kroah-Hartman <[email protected]> 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/[email protected]/
