Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
Date: Mon, 28 Sep 2026 16:58:18 +0000	[thread overview]
Message-ID: <20260928165818.69F321F000FF@smtp.kernel.org> (raw)
In-Reply-To: <a92a69151266129e20abc4a8ec543d4f4438324e.1790612298.git.u.kleine-koenig@baylibre.com>

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?

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/cover.1790612298.git.u.kleine-koenig@baylibre.com?part=2

  reply	other threads:[~2026-09-28 16:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 16:46 [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-28 16:46 ` [PATCH v3 1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted Uwe Kleine-König
2026-09-28 17:25   ` Bradley Morgan
2026-09-28 16:46 ` [PATCH v3 2/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-28 16:58   ` sashiko-bot [this message]
2026-09-28 19:43     ` Uwe Kleine-König
2026-09-28 17:25   ` Bradley Morgan
2026-09-28 16:46 ` [PATCH v3 3/3] driver core: Disable driver overriding by default Uwe Kleine-König
2026-09-28 16:57   ` sashiko-bot
2026-09-28 19:47     ` Uwe Kleine-König
2026-09-28 17:26   ` Bradley Morgan
2026-09-28 17:15 ` [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Danilo Krummrich
2026-09-29  5:53   ` Uwe Kleine-König
2026-09-29 10:28     ` Danilo Krummrich
2026-09-28 21:51 ` (subset) " Danilo Krummrich
2026-09-28 21:53   ` Danilo Krummrich
2026-09-29  5:47     ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260928165818.69F321F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=u.kleine-koenig@baylibre.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox