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