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?

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");

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.

-- 
Sashiko AI review · 
https://sashiko.dev/#/patchset/[email protected]?part=2

Reply via email to