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

["Uwe Kleine-König" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

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 <u.kleine-koenig@baylibre.com>
> 
> 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/
> 
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]