Thread (11 messages) 11 messages, 5 authors, 12d ago

Re: [PATCH v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

flat view

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2026-09-27 16:50:37
Also in: driver-core, lkml

On Sun, Sep 27, 2026 at 11:55:39AM +0200, Danilo Krummrich wrote:
On Sun Sep 27, 2026 at 10:03 AM CEST, Uwe Kleine-König wrote:
quoted
Commit fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when
userspace manually messes with devices and drivers") introduced a taint
for usage of bind/unbind sysfs files that manually trigger driver probe
and remove respectively.

For drivers that do their resource management correctly (which is also
needed for module unloading) bind and unbind for matching devices are
not critical operations. The thing that makes bind and unbind unsafe is
that drivers can be forced on devices that originally don't match using
driver_override. The result is that e.g. of_device_get_match_data()
returns NULL despite all .of_match_table entries having a non-NULL
.driver_data member which yields a NULL pointer exception for several
drivers. And given that after setting a driver_override a manual bind is
only one way a driver can be bound to an unexpected device, a separate
taint for such an override is justified.

Reviewed-by: Bradley Morgan <redacted>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Uwe Kleine-König <redacted>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/ (local)
quoted
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index c51ad96d4de4..7d5dc016a457 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -513,6 +513,7 @@ static ssize_t driver_override_store(struct device *dev,
 {
 	int ret;
 
+	add_taint_module(NULL, TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
 	ret = __device_set_driver_override(dev, buf, count);
There are buses (such as SPI) which unfortunately have to call
__device_set_driver_override() directly.
Huh?  That feels wrong, can't we fix s390 and spi instead?  Ok, maybe
not s390, but why is spi doing that?

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help