Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers
Date: Fri, 04 Sep 2026 05:22:08 +0000	[thread overview]
Message-ID: <20260904052208.DF4211F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260904-bind_taint-v3-2-30025465f38a@linuxfoundation.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Tainting the kernel unconditionally on any sysfs bind/unbind operation marks legitimate, standard virtualization and networking setups as tainted.
--

commit 5047195fb07d09f62b1e24672350bc622948fa9e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers

This commit adds a new TAINT_FORCED_BIND flag to track when userspace binds
or unbinds devices via sysfs, aiming to flag potentially unstable fuzzing or
unsupported states. It sets this taint flag unconditionally in the sysfs bind
and unbind store callbacks.

> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index d17bd91490ee4..c51ad96d4de4b 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
[ ... ]
> @@ -241,6 +242,7 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf,
>  
>  	dev = bus_find_device_by_name(bus, NULL, buf);
>  	if (dev && dev->driver == drv) {
> +		add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);

[Severity: High]
Will this unconditionally taint the kernel during officially supported unbind
operations? The sysfs unbind file is the documented UAPI for legitimate
subsystems and setups like VFIO PCI passthrough, DPDK, and USB over IP. 

Applying this taint for standard operations might cause normal enterprise
environments to be permanently marked as tainted, causing valid bug reports
to be ignored, and could trigger panics on systems running with panic_on_taint
enabled.

>  		device_driver_detach(dev);
>  		err = count;
>  	}
[ ... ]
> @@ -264,6 +266,7 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf,
>  
>  	dev = bus_find_device_by_name(bus, NULL, buf);
>  	if (dev && driver_match_device(drv, dev)) {
> +		add_taint_module(drv->owner, TAINT_FORCED_BIND, LOCKDEP_STILL_OK);

[Severity: High]
Similarly, will this mark the kernel as tainted when standard virtualization
daemons or userspace networking tools write to the bind file? Is there a way
to distinguish between abusive fuzzing attempts and normal administrative
actions so we do not invalidate valid bug reports from these common setups?

>  		err = device_driver_attach(drv, dev);
>  		if (!err) {
>  			/* success */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904-bind_taint-v3-0-30025465f38a@linuxfoundation.org?part=2

  reply	other threads:[~2026-09-04  5:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  5:10 [PATCH v3 0/2] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers Greg Kroah-Hartman
2026-09-04  5:10 ` [PATCH v3 1/2] module: pull out add_taint_module() to be public Greg Kroah-Hartman
2026-09-04  5:21   ` sashiko-bot
2026-09-04  5:51     ` Greg Kroah-Hartman
2026-09-04  9:25   ` Petr Pavlu
2026-09-04 12:19     ` Greg Kroah-Hartman
2026-09-04 15:36       ` Petr Pavlu
2026-09-04  5:10 ` [PATCH v3 2/2] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers Greg Kroah-Hartman
2026-09-04  5:22   ` sashiko-bot [this message]
2026-09-04  5:51     ` Greg Kroah-Hartman
2026-09-04 19:46 ` [PATCH v3 0/2] " Armin Wolf
2026-09-05 11:27   ` Greg Kroah-Hartman
2026-09-05 12:51     ` Armin Wolf

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=20260904052208.DF4211F00A3E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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