Documentation/admin-guide/tainted-kernels.rst | 52 ++++++++++++++------------- drivers/base/bus.c | 3 ++ include/linux/module.h | 10 ++++++ include/linux/panic.h | 3 +- include/trace/events/module.h | 3 +- kernel/module/main.c | 17 +++++++-- kernel/panic.c | 10 +++--- tools/debugging/kernel-chktaint | 8 +++++ 8 files changed, 73 insertions(+), 33 deletions(-)
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 to work around
the lack of will to upgrade a kernel image to a newer version with
proper support for new devices, or the lack of will to submit valid
device ids to driver authors, will still work properly, but now the
kernel will be flagged in a way that will show that perhaps those users
should reconsider their behavior and work to have the drivers properly
support these devices in a "native" manner.
Finally, the bind/unbind files can find real use-after-free issues with
some drivers by forcing the process to happen virtually without having
to rely on manual removal processes. Those real bugs should still be
worked on, but by adding this taint flag, developers can more easily
determine bug reports that are actually worth looking at.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Changes in v4:
- add documentation fixup for add_taint() and add_taint_module()
- Link to v3: https://patch.msgid.link/20260904-bind_taint-v3-0-30025465f38a@linuxfoundation.org
Changes in v3:
- Fixes based on sashiko review:
- Fix up prototype for when CONFIG_MODULES is disabled so it will
build properly, AGAIN.
- Link to v2: https://patch.msgid.link/20260831-bind_taint-v2-0-1082d631213b@linuxfoundation.org
Changes in v2:
- rebase on 7.3-rc1
- Add changelog text to describe panic_on_taint and how it should be set
for tools like syzbot.
- Add changelog text to describe why 'Y' was picked.
- Fixes based on sashiko review:
- Make add_taint_module() handle a NULL for module pointer, fixing a
problem with built-in drivers.
- Fix up prototype for when CONFIG_MODULES is disabled so it will
actually build properly.
- rst table header fixes.
- Link to v1: https://patch.msgid.link/20260826-bind_taint-v1-0-52b05f4a965c@linuxfoundation.org
To: Luis Chamberlain <mcgrof@kernel.org>
To: Petr Pavlu <petr.pavlu@suse.com>
To: Daniel Gomez <da.gomez@kernel.org>
To: Sami Tolvanen <samitolvanen@google.com>
To: Aaron Tomlin <atomlin@atomlin.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Randy Dunlap <rdunlap@infradead.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: driver-core@lists.linux.dev
Cc: linux-trace-kernel@vger.kernel.org
---
Greg Kroah-Hartman (3):
module: pull out add_taint_module() to be public
module: fix up documentation for add_taint() and add_taint_module()
driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers
Documentation/admin-guide/tainted-kernels.rst | 52 ++++++++++++++-------------
drivers/base/bus.c | 3 ++
include/linux/module.h | 10 ++++++
include/linux/panic.h | 3 +-
include/trace/events/module.h | 3 +-
kernel/module/main.c | 17 +++++++--
kernel/panic.c | 10 +++---
tools/debugging/kernel-chktaint | 8 +++++
8 files changed, 73 insertions(+), 33 deletions(-)
---
base-commit: 704340f1cd0dcef829eb62f5b48ae95a2ce17bdf
change-id: 20260825-bind_taint-d4077b870bc4
Best regards,
--
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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. Acked-by: Danilo Krummrich <dakr@kernel.org> > to work around > the lack of will to upgrade a kernel image to a newer version with > proper support for new devices, or the lack of will to submit valid > device ids to driver authors, will still work properly, but now the > kernel will be flagged in a way that will show that perhaps those users > should reconsider their behavior and work to have the drivers properly > support these devices in a "native" manner. > > Finally, the bind/unbind files can find real use-after-free issues with > some drivers by forcing the process to happen virtually without having > to rely on manual removal processes. Those real bugs should still be > worked on, but by adding this taint flag, developers can more easily > determine bug reports that are actually worth looking at. > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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.
So please let's do
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index c51ad96d4de4..ce8fb14ea19a 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -242,7 +242,6 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf,
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == drv) {
- add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
device_driver_detach(dev);
err = count;
}
@@ -266,7 +265,6 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf,
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && driver_match_device(drv, dev)) {
- add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
err = device_driver_attach(drv, dev);
if (!err) {
/* success */
@@ -513,6 +511,7 @@ static ssize_t driver_override_store(struct device *dev,
{
int ret;
+ add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
ret = __device_set_driver_override(dev, buf, count);
if (ret)
return ret;
(plus the needed documentation adaptions and maybe a rename
s/TAINT_FORCED_BIND/TAINT_DRIVER_OVERRIDE/).
Best regards
Uwe
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.
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.
>
> So please let's do
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index c51ad96d4de4..ce8fb14ea19a 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -242,7 +242,6 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf,
>
> dev = bus_find_device_by_name(bus, NULL, buf);
> if (dev && dev->driver == drv) {
> - add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
> device_driver_detach(dev);
> err = count;
> }
> @@ -266,7 +265,6 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf,
>
> dev = bus_find_device_by_name(bus, NULL, buf);
> if (dev && driver_match_device(drv, dev)) {
> - add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
> err = device_driver_attach(drv, dev);
> if (!err) {
> /* success */
> @@ -513,6 +511,7 @@ static ssize_t driver_override_store(struct device *dev,
> {
> int ret;
>
> + add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
> ret = __device_set_driver_override(dev, buf, count);
> if (ret)
> return ret;
>
> (plus the needed documentation adaptions and maybe a rename
> s/TAINT_FORCED_BIND/TAINT_DRIVER_OVERRIDE/).
>
> Best regards
> Uwe
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?
Thanks,
Armin Wolf
>> So please let's do
>>
>> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
>> index c51ad96d4de4..ce8fb14ea19a 100644
>> --- a/drivers/base/bus.c
>> +++ b/drivers/base/bus.c
>> @@ -242,7 +242,6 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf,
>>
>> dev = bus_find_device_by_name(bus, NULL, buf);
>> if (dev && dev->driver == drv) {
>> - add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
>> device_driver_detach(dev);
>> err = count;
>> }
>> @@ -266,7 +265,6 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf,
>>
>> dev = bus_find_device_by_name(bus, NULL, buf);
>> if (dev && driver_match_device(drv, dev)) {
>> - add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
>> err = device_driver_attach(drv, dev);
>> if (!err) {
>> /* success */
>> @@ -513,6 +511,7 @@ static ssize_t driver_override_store(struct device *dev,
>> {
>> int ret;
>>
>> + add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);
>> ret = __device_set_driver_override(dev, buf, count);
>> if (ret)
>> return ret;
>>
>> (plus the needed documentation adaptions and maybe a rename
>> s/TAINT_FORCED_BIND/TAINT_DRIVER_OVERRIDE/).
>>
>> Best regards
>> Uwe
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. 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. thanks, greg k-h
Am 23.09.26 um 11:27 schrieb Greg Kroah-Hartman: > 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. From my perspective rmmod and friends are at least expected to not crash the kernel. >>> 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? Netlink UAPI <-> generic driver <-> WMI device User will need to manually bind the generic driver (it really supports all WMI devices!) to a given WMI device, something that is only possible with bind/unbind. >> 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. > > Please, learn from our history, don't make the same mistakes. I meant with that, that drivers should be prepared that for example of_device_get_match_data() returns a NULL pointer. In Rust drivers would have to check for this anyway, so i see little reason why drivers written in C should skip this check and as a result break as soon as someone uses driver_override (or they are matched against a non-OF device). > 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. > > thanks, > > greg k-h I understand your concerns, but IMHO it turned out that bind/unbind are useful outside of debugging. I agree that userspace using bind/unbind should not be considered normal, but in my opinion its far from being suspicious. Manually unbinding a specific drivers in order to bind a generic driver is unusual, but understandable. I agree with you that driver_override should be the correct place for such a taint, because using driver_override indeed overrides the bus-specific matching logic and can therefore be dangerous. Thanks, Armin Wolf
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
On Wed, Sep 23, 2026 at 11:54:50AM +0200, Uwe Kleine-König wrote: > > 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. Agreed, yes, root can cause a crash and can do tons of horrible things much worse than this, that's not the issue. That's why this taint is there, to make it obvious that this is not a "real" bug at all. > > 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. Fine, use it! Just don't expect that to be "normal". > So yes, theoretically bind/unbind isn't needed, but theory and practise > differ in practise. Agreed, but again, don't rely on this as a "real" solution fo ranything. > 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. How is that going to change anything? Confused. greg k-h
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
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! greg k-h
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/
© 2016 - 2026 Red Hat, Inc.