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 v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
Date: Sun, 27 Sep 2026 08:13:17 +0000 [thread overview]
Message-ID: <20260927081317.D44771F000FF@smtp.kernel.org> (raw)
In-Reply-To: <01d7a085e56b860e83b65c96ff3dd86c4498804b.1790495516.git.u.kleine-koenig@baylibre.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] sysfs: driver_override taint is bypassed by subsystem-specific callbacks
- [Medium] sysfs: restoring default driver binding unconditionally taints the kernel
- [Low] trace: TAINT_DRIVER_OVERRIDE bit in module_load event is dead code
- [Low] panic: off-by-one calculation in verbose taint string comment
--
commit a5915871a0d2d9897b48b1d7e230f229bd1e51f7
Author: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Add TAINT_DRIVER_OVERRIDE for usage of driver_override
This commit introduces a new taint flag, TAINT_DRIVER_OVERRIDE, to track when
userspace manually triggers driver binding via the driver_override sysfs file.
It includes updates to the core bus sysfs callbacks, documentation, and the
module tracepoint definitions.
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index c51ad96d4de4b..7d5dc016a457c 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -513,6 +513,7 @@ static ssize_t driver_override_store(struct device *dev,
> {
> int ret;
>
> + add_taint_module(NULL, TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
[Severity: Medium]
Does this unconditionally taint the kernel even when restoring the default
driver binding?
If userspace writes an empty string or a newline to clear a previous override,
the kernel is permanently marked as tainted. This seems to contradict the
intent of only tainting when forcing a driver.
[Severity: Medium]
Is this taint bypassed by subsystem-specific callbacks?
Subsystems like SPI and AP queue define their own custom driver_override_store
callbacks which directly call __device_set_driver_override() and completely
skip this new taint injection.
For example, in drivers/spi/spi.c:
static ssize_t driver_override_store(...)
{
...
ret = __device_set_driver_override(dev, buf, count);
...
}
Should this taint be applied within __device_set_driver_override() instead
to catch these custom subsystem sysfs callbacks?
> ret = __device_set_driver_override(dev, buf, count);
> if (ret)
> return ret;
[ ... ]
> diff --git a/include/trace/events/module.h b/include/trace/events/module.h
> index 19df3e39bba43..c7cdb1f53bc64 100644
> --- a/include/trace/events/module.h
> +++ b/include/trace/events/module.h
> @@ -27,7 +27,8 @@ struct module;
> { (1UL << TAINT_FORCED_MODULE), "F" }, \
> { (1UL << TAINT_CRAP), "C" }, \
> { (1UL << TAINT_UNSIGNED_MODULE), "E" }, \
> - { (1UL << TAINT_FORCED_BIND), "Y" })
> + { (1UL << TAINT_FORCED_BIND), "Y" }, \
> + { (1UL << TAINT_DRIVER_OVERRIDE), "Z" })
[Severity: Low]
Is this trace bit reachable?
Since add_taint_module(NULL, TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK) is
called with NULL rather than a struct module, the taint is only applied
globally to the kernel.
Because the bit is never set in any individual module's taints bitmask, adding
this to the module trace event flags appears to be dead code.
>
> TRACE_EVENT(module_load,
[ ... ]
> diff --git a/kernel/panic.c b/kernel/panic.c
> index b824b68fcb084..f5476a61f6f39 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
[ ... ]
> @@ -862,7 +863,7 @@ static void print_tainted_seq(struct seq_buf *s, bool verbose)
> * exact size is allocated dynamically; the initial buffer remains
> * as a fallback if allocation fails.
> *
> - * The verbose taint string currently requires up to 344 characters.
> + * The verbose taint string currently requires up to 364 characters.
[Severity: Low]
Does this undercount the required buffer size by one character?
The newly added DRIVER_OVERRIDE flag requires exactly 21 characters (15 for
the descriptor "DRIVER_OVERRIDE", 2 for the ", " separator, and 4 for the
format "[Z]=").
The true required length without the null terminator would be 344 + 21 = 365
characters. INIT_TAINT_BUF_MAX is sufficiently padded (370) so this doesn't
cause an overflow, but the documentation appears to have an off-by-one.
> */
> #define INIT_TAINT_BUF_MAX 370
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790495516.git.u.kleine-koenig@baylibre.com?part=2
next prev parent reply other threads:[~2026-09-27 8:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 8:03 [PATCH v2 0/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-27 8:03 ` [PATCH v2 1/2] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted Uwe Kleine-König
2026-09-27 16:39 ` Randy Dunlap
2026-09-27 8:03 ` [PATCH v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-27 8:13 ` sashiko-bot [this message]
2026-09-27 9:55 ` Danilo Krummrich
2026-09-27 10:03 ` Danilo Krummrich
2026-09-28 8:50 ` Uwe Kleine-König
2026-09-28 9:17 ` Danilo Krummrich
2026-09-27 16:50 ` Greg Kroah-Hartman
2026-09-27 17:12 ` Danilo Krummrich
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=20260927081317.D44771F000FF@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