On Mon, Sep 28, 2026 at 04:58:18PM +0000, [email protected] 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 <[email protected]> > > 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/[email protected]/ > > > 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
signature.asc
Description: PGP signature
