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

On Mon, Sep 28, 2026 at 04:58:18PM +0000, sashiko-bot@kernel.org wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] device: false kernel taint from internal driver_override usage
--

commit 224a6c2cd832599abb4180f63153f96e5c11d2a8
Author: Uwe Kleine-König [off-list ref]

Add TAINT_DRIVER_OVERRIDE for usage of driver_override

This commit introduces a new kernel taint, TAINT_DRIVER_OVERRIDE, which is
applied when a driver is matched to a device via the driver_override
mechanism. It aims to distinguish overrides from manual sysfs bindings, as
overrides can lead to driver crashes if the driver expects specific match data.

Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/ (local)

quoted

diff --git a/include/linux/device.h b/include/linux/device.h
index 879eb758b5eec..4dac5e09b74c1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h

@@ -905,8 +905,15 @@ static inline int device_match_driver_override(struct device *dev,
 					       const struct device_driver *drv)
 {
 	guard(spinlock)(&dev->driver_override.lock);
-	if (dev->driver_override.name)
-		return !strcmp(dev->driver_override.name, drv->name);
+	if (dev->driver_override.name) {
+		int ret = !strcmp(dev->driver_override.name, drv->name);
+
+		if (ret > 0)
+			add_taint_module(drv->owner,
+					 TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);

[Severity: Medium]
Will this unconditionally taint the kernel even for valid internal usages of
driver_override?

Well, if you assume there are valid internal usages of driver_override,
yes. I think it is possible to not need these all.
 

Many kernel subsystems and drivers use device_set_driver_override()
programmatically to force driver matching for dynamically instantiated devices
during normal operation or probing.

For example, in drivers/clk/imx/clk-scu.c:imx_clk_scu_alloc_dev() sets the
override internally:

	ret = device_set_driver_override(&pdev->dev, "imx-scu-clk");

Here I think you need to change `platform_device_alloc(name,
PLATFORM_DEVID_NONE)` to `platform_device_alloc("imx-scu-clk",
PLATFORM_DEVID_NONE)` plus maybe create uniq device ids (using a static
int that is increased for each call).

Since device_match_driver_override() cannot distinguish between a userspace
sysfs override and a legitimate internal programmatic override, won't this
cause production systems using these platforms to falsely report as tainted on
boot?

Falsely tainting the kernel breaks the reliability of the taint mechanism and
could lead to valid bug reports being ignored by maintainers.

Best regards
Uwe