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 | 16 +++++++-- kernel/panic.c | 5 +-- tools/debugging/kernel-chktaint | 8 +++++ 8 files changed, 69 insertions(+), 31 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 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 (2):
module: pull out add_taint_module() to be public
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 | 16 +++++++--
kernel/panic.c | 5 +--
tools/debugging/kernel-chktaint | 8 +++++
8 files changed, 69 insertions(+), 31 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260825-bind_taint-d4077b870bc4
Best regards,
--
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Am 04.09.26 um 07:10 schrieb Greg Kroah-Hartman:
> 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.
What about users that use driver_override together with vfio-pci? AFAIK
they still need to write to bind/unbind.
Also i always liked the fact that the bind/unbind attributes make it very
easy in creating generic drivers. In fact, i am intending to use this feature
in order to add netlink support to the ACPI-WMI subsystem in the future.
I am planning to realize this thru a generic WMI driver that has to be manually
bound to a given WMI device to make it available over netlink, so having
users be able to write bind/unbind without potentially triggering a kernel panic
would be very nice.
Additionally, writing into the bind attribute still checks if the driver and the
device match:
/*
* Manually attach a device to a driver.
* Note: the driver must want to bind to the device,
* it is not possible to override the driver's id table.
*/
static ssize_t bind_store(struct device_driver *drv, const char *buf, size_t count)
Because of this i would suggest that the taint (if at all) be added to the
driver_override attribute instead, because only with this attribute users can bind
random drivers to truly random devices.
Thanks,
Armin Wolf
> 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 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 (2):
> module: pull out add_taint_module() to be public
> 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 | 16 +++++++--
> kernel/panic.c | 5 +--
> tools/debugging/kernel-chktaint | 8 +++++
> 8 files changed, 69 insertions(+), 31 deletions(-)
> ---
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> change-id: 20260825-bind_taint-d4077b870bc4
>
> Best regards,
> --
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>
> From mboxrd@z Thu Jan 1 00:00:00 1970
> Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
> (No client certificate requested)
> by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCB7D415F06;
> Fri, 4 Sep 2026 05:12:34 +0000 (UTC)
> Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
> ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
> t=1788498755; cv=none; b=YVFqay1IJUVOWRhF5lbF49N9gACjWl/u/wiBGdeV8d9eqXk9mnp+dQ6eyjskPf1vqMRfNXCLudsRqs7s/ptpX2bQJsQ4PyAt97qclTSJBOznKuYqjuVxufSShWBSj6iGoGnZcQw+e2Q9Ly6ixw+Q323AmyXIc+H/caHtjxakuHk=
> ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
> s=arc-20240116; t=1788498755; c=relaxed/simple;
> bh=pLyyPJCavNnqg1J4ue9yK5PlAmiMR++3Z8v4Ev3jR+4=;
> h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
> In-Reply-To:To:Cc; b=NoNrP4+kG51E+VUVjTQ7eZBG8DJ4QJdPSX7nXCHR7qNw1HzTheBF+APlqE/yPFE/HDXCloQq6PsRH784NlK0lTDBu81Xo9PlS0QhLQkafpUGps8FcEw2pQZxbhT+91ISzyOG0uOnSka9ty7gwBGsyKlxA8KNYgFLv4Jpuyl3CxU=
> ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ucn4lrR/; arc=none smtp.client-ip=100.103.45.18
> Authentication-Results: smtp.subspace.kernel.org;
> dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ucn4lrR/"
> Received: by smtp.kernel.org (Postfix) with ESMTPSA id 003711F00A3E;
> Fri, 4 Sep 2026 05:12:33 +0000 (UTC)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org;
> s=korg; t=1788498754;
> bh=KrAwo9/bReRcHGrb+EIOBXbKoLVbmnWAiqQj4hM9GR4=;
> h=From:Date:Subject:References:In-Reply-To:To:Cc;
> b=ucn4lrR/Wvs8Hzz+jBIP38JWRP4T8gs3TOfl/opgMz+qXDSpJTTmTld3GSYkHx+b1
> pqksgdzktExbEkSrSC3Poy+I6JfuzXpXH199wNaRrrq4ei16vWNsuDsnGyxgiHzh0C
> nbHTwZKC7lvKjyIz2vK00XrqIQLoA4eUS5NrG24U=
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Fri, 04 Sep 2026 07:10:41 +0200
> Subject: [PATCH v3 1/2] module: pull out add_taint_module() to be public
> Precedence: bulk
> X-Mailing-List: linux-modules@vger.kernel.org
> List-Id: <linux-modules.vger.kernel.org>
> List-Subscribe: <mailto:linux-modules+subscribe@vger.kernel.org>
> List-Unsubscribe: <mailto:linux-modules+unsubscribe@vger.kernel.org>
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 7bit
> Message-Id: <20260904-bind_taint-v3-1-30025465f38a@linuxfoundation.org>
> References: <20260904-bind_taint-v3-0-30025465f38a@linuxfoundation.org>
> In-Reply-To: <20260904-bind_taint-v3-0-30025465f38a@linuxfoundation.org>
> To: Luis Chamberlain <mcgrof@kernel.org>, Petr Pavlu <petr.pavlu@suse.com>,
> Daniel Gomez <da.gomez@kernel.org>, Sami Tolvanen <samitolvanen@google.com>,
> Aaron Tomlin <atomlin@atomlin.com>, Jonathan Corbet <corbet@lwn.net>,
> Shuah Khan <skhan@linuxfoundation.org>,
> Randy Dunlap <rdunlap@infradead.org>,
> "Rafael J. Wysocki" <rafael@kernel.org>, Danilo Krummrich <dakr@kernel.org>,
> Steven Rostedt <rostedt@goodmis.org>,
> Masami Hiramatsu <mhiramat@kernel.org>,
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Bradley Morgan <brads@mainlining.org>,
> Aleksandr Nogikh <nogikh@google.com>, linux-modules@vger.kernel.org,
> linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
> linux-usb@vger.kernel.org, driver-core@lists.linux.dev,
> linux-trace-kernel@vger.kernel.org,
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
> Johan Hovold <johan@kernel.org>
> X-Mailer: b4 0.17-dev-362b8
> X-Developer-Signature: v=1; a=openpgp-sha256; l=2682;
> i=gregkh@linuxfoundation.org; h=from:subject:message-id;
> bh=pLyyPJCavNnqg1J4ue9yK5PlAmiMR++3Z8v4Ev3jR+4=;
> b=owGbwMvMwCRo6H6F97bub03G02pJDFmzgq4fWPbWcV/uvHnfg/ZMrU9bv71xatg7tVk7novmL
> 1mmFli4riOWhUGQiUFWTJHlyzaeo/srDil6GdqehpnDygQyhIGLUwAmosTDMIdTKWjC6aIHLY+P
> emcEXORcfPbdG0mGuULdv/erqSxsnFs4z/HElrKuTU5rdAE=
> X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp;
> fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29
>
> Other kernel code might want to call add_taint_module() so pull it out
> and make it global. If modules are not enabled, this defaults to a call
> to add_taint(), so all is fine.
>
> Reviewed-by: Johan Hovold <johan@kernel.org>
> Tested-by: Johan Hovold <johan@kernel.org>
> Reviewed-by: Bradley Morgan <brads@mainlining.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> include/linux/module.h | 10 ++++++++++
> kernel/module/main.c | 16 +++++++++++++---
> 2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 96cc98568eea..f6f90cd88f15 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -29,6 +29,7 @@
> #include <linux/srcu.h>
> #include <linux/static_call_types.h>
> #include <linux/dynamic_debug.h>
> +#include <linux/panic.h>
>
> #include <linux/percpu.h>
> #include <asm/module.h>
> @@ -770,6 +771,9 @@ static inline bool is_livepatch_module(struct module *mod)
>
> void module_for_each_mod(int(*func)(struct module *mod, void *data), void *data);
>
> +void add_taint_module(struct module *mod, unsigned flag,
> + enum lockdep_ok lockdep_ok);
> +
> #else /* !CONFIG_MODULES... */
>
> static inline struct module *__module_address(unsigned long addr)
> @@ -877,6 +881,12 @@ static inline bool module_is_coming(struct module *mod)
> static inline void module_for_each_mod(int(*func)(struct module *mod, void *data), void *data)
> {
> }
> +
> +static inline void add_taint_module(struct module *mod, unsigned flag,
> + enum lockdep_ok lockdep_ok)
> +{
> + add_taint(flag, lockdep_ok);
> +}
> #endif /* CONFIG_MODULES */
>
> #ifdef CONFIG_SYSFS
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index d0e1e0bd2ad0..444d990c9983 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -191,11 +191,21 @@ static inline int strong_try_module_get(struct module *mod)
> return -ENOENT;
> }
>
> -static inline void add_taint_module(struct module *mod, unsigned flag,
> - enum lockdep_ok lockdep_ok)
> +/**
> + * add_taint_module: add a taint flag if not already set for a specific module
> + * @mod: pointer to the module that caused the problem
> + * @flag: one of the TAINT_* constants.
> + * @lockdep_ok: whether lock debugging is still OK.
> + *
> + * If something bad has gone wrong, you'll want @lockdebug_ok = false, but for
> + * some noteworthy-but-not-corrupting cases, it can be set to true.
> + */
> +void add_taint_module(struct module *mod, unsigned flag,
> + enum lockdep_ok lockdep_ok)
> {
> add_taint(flag, lockdep_ok);
> - set_bit(flag, &mod->taints);
> + if (mod)
> + set_bit(flag, &mod->taints);
> }
>
> /*
>
On Fri, Sep 04, 2026 at 09:46:59PM +0200, Armin Wolf wrote: > > Am 04.09.26 um 07:10 schrieb Greg Kroah-Hartman: > > 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. > > What about users that use driver_override together with vfio-pci? AFAIK > they still need to write to bind/unbind. As I state above, that is an abuse of this api. > Also i always liked the fact that the bind/unbind attributes make it very > easy in creating generic drivers. In fact, i am intending to use this feature > in order to add netlink support to the ACPI-WMI subsystem in the future. > I am planning to realize this thru a generic WMI driver that has to be manually > bound to a given WMI device to make it available over netlink, so having > users be able to write bind/unbind without potentially triggering a kernel panic > would be very nice. It's a taint flag being set, not a panic, showing developers that "hey, the user just did something odd here, ask them about it when handling this bug report." > Additionally, writing into the bind attribute still checks if the driver and the > device match: > > /* > * Manually attach a device to a driver. > * Note: the driver must want to bind to the device, > * it is not possible to override the driver's id table. > */ > static ssize_t bind_store(struct device_driver *drv, const char *buf, size_t count) > > Because of this i would suggest that the taint (if at all) be added to the > driver_override attribute instead, because only with this attribute users can bind > random drivers to truly random devices. I had thought of that, but the force removal of drivers from devices wouldn't show up this way, which is one of the things that we do want to warn developers about. And, if we just did the driver_override taint, it would allow those drivers who claim to be "generic" like you are referring to, to keep "getting away with that" when it's obviously not true that they can handle any device for that bus, otherwise it would have automatically bound to it already (and no manual intervention would be needed.) By keeping the manual configuration of bind, you are forcing userspace to manually do work, while still a possible thing to do, now at least a developer who gets a bug report will _know_ it happened, which is why the taint flag is there. Does that make a bit more sense? thanks, greg k-h
Am 05.09.26 um 13:27 schrieb Greg Kroah-Hartman: > On Fri, Sep 04, 2026 at 09:46:59PM +0200, Armin Wolf wrote: >> Am 04.09.26 um 07:10 schrieb Greg Kroah-Hartman: >>> 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. >> What about users that use driver_override together with vfio-pci? AFAIK >> they still need to write to bind/unbind. > As I state above, that is an abuse of this api. > >> Also i always liked the fact that the bind/unbind attributes make it very >> easy in creating generic drivers. In fact, i am intending to use this feature >> in order to add netlink support to the ACPI-WMI subsystem in the future. >> I am planning to realize this thru a generic WMI driver that has to be manually >> bound to a given WMI device to make it available over netlink, so having >> users be able to write bind/unbind without potentially triggering a kernel panic >> would be very nice. > It's a taint flag being set, not a panic, showing developers that "hey, > the user just did something odd here, ask them about it when handling > this bug report." >> Additionally, writing into the bind attribute still checks if the driver and the >> device match: >> >> /* >> * Manually attach a device to a driver. >> * Note: the driver must want to bind to the device, >> * it is not possible to override the driver's id table. >> */ >> static ssize_t bind_store(struct device_driver *drv, const char *buf, size_t count) >> >> Because of this i would suggest that the taint (if at all) be added to the >> driver_override attribute instead, because only with this attribute users can bind >> random drivers to truly random devices. > I had thought of that, but the force removal of drivers from devices > wouldn't show up this way, which is one of the things that we do want to > warn developers about. IMHO drivers that do not support this should rather just set suppress_bind_attrs. And drivers for busses that do support hotplugging must support surprise removal anyway. Would it be possible to only taint the kernel if the underlying bus does not claim to be hotplugable? > And, if we just did the driver_override taint, it would allow those > drivers who claim to be "generic" like you are referring to, to keep > "getting away with that" when it's obviously not true that they can > handle any device for that bus, otherwise it would have automatically > bound to it already (and no manual intervention would be needed.) > > By keeping the manual configuration of bind, you are forcing userspace > to manually do work, while still a possible thing to do, now at least a > developer who gets a bug report will _know_ it happened, which is why > the taint flag is there. > > Does that make a bit more sense? How are users supposed to select between multiple drivers for the same device if all those drivers claim to support said device? Assuming i have a generic driver and a more specialized driver that both claim support for the same device. How can i control which one is ultimately bound to the device without using bind/unbind? How to utilize driver_override when another driver is already bound to the device without using the unbind attribute? Also drivers that claim to be generic while obviously not being able to handle all devices are themselves broken, not the surrounding mechanism that relies on the data being supplied by the broken drivers. Maybe we should instead fix those drivers to stop claiming to be generic? Do you know the names of some drivers that are affected by this? Thanks, Armin Wolf > thanks, > > greg k-h
© 2016 - 2026 Red Hat, Inc.