[PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Uwe Kleine-König]

Hello,

this series unifies two different approaches:

 - tainting the kernel on setting up a driver_override
 - disabling driver_override by default, with giving drivers the ability
   to allow themselves in.

The first is an idea that arised by Greg implementing a taint for
writing to the bind and unbind driver properties. Both Danilo and me
came up with the theory that driver_override is the real culprit if
manual binding is problematic.

The second originates from an effort by Thierry who implemented the
reverse of patch #3: Drivers could opt-out of driver_overriding. See
https://lore.kernel.org/lkml/20260922-driver-override-opt-out-v1-0-58c35ded3b83@nvidia.com
. This patch is new compared to the v2 series with the same subject.

Note that different to Danilo's suggestion I don't differentiate between
driver_overrides setup in userspace and those setup in kernel space.
IMHO all are bad and there are alternatives for the legitimate cases.
Also I didn't make an effort to identify drivers that should continue to
be able to override a driver. This can still be done when patch #3 is
considered to be the way to go. (And I'm sure that it will be noticed
quickly if we miss a legitimate use case. Still I think forbidding
driver_override should cook in next for a while before it's merged to
catch at least the most common cases.)

I think applying this complete patch set and keeping fcbfaffee51a ("driver
core: add TAINT_FORCED_BIND for when userspace manually messes with devices and
drivers") is too much, so this series serves mainly as discussion ground for
choosing a sane way to prevent fuzzing results of only mild interest and stop
patch sets harding drivers for driver_override handling.
My preference would be to revert (or drop) fcbfaffee51a and then only
apply patch #3. Maybe also keep patch #2 to taint if
"allow_driver_override" is provided.

To make it possible to let a driver allow being used in an override, the place
where the check if the override should be honered had to move, as the place
where it was checked in v2 didn't have the driver available. As this is a
relevant change I dropped the Acks I already received. Also an upside is that
this way the module is known that contains the overridden driver.

My test-case was using the tegra-pwm driver, which I could trigger using:

	cd /sys/bus/platform
	echo tegra-pwm > devices/watchdog/driver_override
	modprobe pwm-tegra

on an stm32mp135. With this patchset applied this either ends in:

	[   65.243492] Suppress driver override binding. Allow tegra_pwm_driver [pwm_tegra] to do overriding or boot with allow_driver_override on cmdline

(when the kernel parameter isn't provided) or

	[   65.440208] 8<--- cut here ---
	[   65.441886] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
	[   65.452547] [00000000] *pgd=00000000
	[   65.454748] Internal error: Oops: 5 [#1] SMP ARM
	[   65.459397] Modules linked in: pwm_tegra(Z+)
	[   65.463664] CPU: 0 UID: 0 PID: 243 Comm: modprobe Tainted: G                    Z 7.3.0-rc4-next-20260925+ #52 PREEMPT 
	[   65.474443] Tainted: [Z]=DRIVER_OVERRIDE
	[   65.478378] Hardware name: STM32 (Device Tree Support)
	[   65.483519] PC is at tegra_pwm_probe+0x20/0x224 [pwm_tegra]
	[   65.488995] LR is at _raw_spin_unlock_irqrestore+0x3c/0x68
	[   65.494555] pc : [<bf00014c>]    lr : [<c0fbb22c>]    psr: 60010013
	[   65.500803] sp : c56bbd18  ip : 00000000  fp : 0043b2f0
	[   65.506045] r10: c1d99d8c  r9 : c174c220  r8 : 00000000
	[   65.511188] r7 : bf002014  r6 : c201b000  r5 : bf002014  r4 : c201b010
	[   65.517736] r3 : 00000004  r2 : 00000018  r1 : 00000001  r0 : 00000000
	[   65.524286] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
	[   65.531441] Control: 10c5387d  Table: c525806a  DAC: 00000051
	[   65.537185] Register r0 information: NULL pointer
	[   65.541839] Register r1 information: non-paged memory
	[   65.546888] Register r2 information: non-paged memory
	[   65.551937] Register r3 information: non-paged memory
	[   65.556986] Register r4 information: slab kmalloc-1k start c201b000 pointer offset 16 size 1024
	[   65.565689] Register r5 information: 1-page vmalloc region starting at 0xbf002000 allocated at load_module+0x830/0x21fc
	[   65.576486] Register r6 information: slab kmalloc-1k start c201b000 pointer offset 0 size 1024
	[   65.585085] Register r7 information: 1-page vmalloc region starting at 0xbf002000 allocated at load_module+0x830/0x21fc
	[   65.595873] Register r8 information: NULL pointer
	[   65.600521] Register r9 information: non-slab/vmalloc memory
	[   65.606174] Register r10 information: non-slab/vmalloc memory
	[   65.611927] Register r11 information: non-paged memory
	[   65.617076] Register r12 information: NULL pointer
	[   65.621923] Process modprobe (pid: 243, stack limit = 0x6ee59a55)
	[   65.627977] Stack: (0xc56bbd18 to 0xc56bc000)
	[   65.632320] bd00:                                                       bf002014 c175d098
	[   65.640481] bd20: c201b010 bf002014 c175d098 bf002014 00000000 c0993270 c201b010 00000000
	[   65.648642] bd40: c175d098 c09904bc 0043b2f0 c0fbb128 c201b010 c175d098 bf002014 c201b010
	[   65.656903] bd60: c5183cd8 c09908a8 bf002014 c0fbb098 c5183cd8 c1db524c bf002014 00000031
	[   65.665065] bd80: c201b010 c5183cd8 c174c220 c1d99d8c 0043b2f0 c0990b10 c201b010 bf002014
	[   65.673226] bda0: c0990d08 c2174400 c5183cd8 c0990e0c c174c220 c201b07c 00000000 bf002014
	[   65.681387] bdc0: c0990d08 c098dd3c c21744e0 c21744ac c2017414 3c5c6832 00000000 c5183c80
	[   65.689548] bde0: 00000000 bf002014 c2174400 c098f3dc bf004098 bf006000 bf002014 c160805c
	[   65.697709] be00: 0043b2f0 bf006000 00000000 c0991a1c c2cbd640 c160805c c2cbd640 c0116c60
	[   65.705970] be20: c2001240 dcfb9324 00000cc0 c2cbd640 00000000 c02271d0 00000010 c0453e00
	[   65.714132] be40: 00000cc0 ffffffff c0453c74 00000000 c022999c c15d2324 c565ba80 c02271d0
	[   65.722293] be60: 00000010 00000000 00000000 3c5c6832 00002b1c 3c5c6832 c565ba80 bf002080
	[   65.730454] be80: 0043b2f0 c52f7800 00000000 c373f0f8 c1d99d8c c0227200 00000000 c52f7800
	[   65.738615] bea0: 0043b2f0 c02299c0 c56bbebc 7fffffff 00000000 00000002 c2cbd640 ddaf4000
	[   65.746776] bec0: ddaf515d ddaf4758 ddaf4000 00002b1c ddaf64dc ddaf6358 ddaf59c8 00000340
	[   65.755037] bee0: 00000480 00000cdc 0000061d 00000000 00000ccc 00000025 00000026 0000000e
	[   65.763198] bf00: 00000000 0000001d 00000000 00000000 00000000 3c5c6832 c52f7800 c1d99d10
	[   65.771359] bf20: c1d99d00 c0229dc0 c56bbfb0 c0100290 c0100290 0000001f c373f0f8 00000000
	[   65.779521] bf40: c1d99d8c 00000000 00000000 dead4ead ffffffff ffffffff c1d9a110 00000000
	[   65.787682] bf60: 00000000 c1313314 c0000200 c56bbf6c c56bbf6c fffffffc bea8191c 3c5c6832
	[   65.795843] bf80: 00000006 00000000 01f4e1f8 00000000 0000017b c0100290 c2cbd640 0000017b
	[   65.804105] bfa0: 00000000 c0100060 00000000 01f4e1f8 00000003 0043b2f0 00000000 00000000
	[   65.812266] bfc0: 00000000 01f4e1f8 00000000 0000017b 01f4d290 0043e0a8 00000001 00000000
	[   65.820427] bfe0: bea81940 bea81930 00436d83 b6ef28f2 40010030 00000003 00000000 00000000
	[   65.828581] Call trace: 
	[   65.828603]  tegra_pwm_probe [pwm_tegra] from platform_probe+0x64/0x98
	[   65.837609]  platform_probe from really_probe+0xe8/0x424
	[   65.842974]  really_probe from __driver_probe_device+0xb0/0x234
	[   65.848834]  __driver_probe_device from driver_probe_device+0x3c/0xc0
	[   65.855298]  driver_probe_device from __driver_attach+0x104/0x238
	[   65.861359]  __driver_attach from bus_for_each_dev+0x78/0xc8
	[   65.867018]  bus_for_each_dev from bus_add_driver+0xe8/0x238
	[   65.872674]  bus_add_driver from driver_register+0x8c/0x140
	[   65.878232]  driver_register from do_one_initcall+0x74/0x3f8
	[   65.883902]  do_one_initcall from do_init_module+0x58/0x24c
	[   65.889469]  do_init_module from init_module_from_file+0xf0/0x10c
	[   65.895634]  init_module_from_file from sys_finit_module+0x150/0x330
	[   65.901901]  sys_finit_module from ret_fast_syscall+0x0/0x1c
	[   65.907561] Exception stack(0xc56bbfa8 to 0xc56bbff0)
	[   65.912609] bfa0:                   00000000 01f4e1f8 00000003 0043b2f0 00000000 00000000
	[   65.920871] bfc0: 00000000 01f4e1f8 00000000 0000017b 01f4d290 0043e0a8 00000001 00000000
	[   65.929029] bfe0: bea81940 bea81930 00436d83 b6ef28f2
	[   65.934078] Code: e1a06000 e2800010 eb71038f e3a02018 (e5901000) 
	[   65.941032] ---[ end trace 0000000000000000 ]---

Also the comment in patch #2 was fixed for the off-by-one that Sashiko found,
the remaining feedback doesn't apply any more.

Best regards
Uwe

Uwe Kleine-König (3):
  docs: admin-guide: Handle TAINT_FORCED_BIND when parsing
    /proc/sys/kernel/tainted
  Add TAINT_DRIVER_OVERRIDE for usage of driver_override
  driver core: Disable driver overriding by default

 Documentation/admin-guide/tainted-kernels.rst |  6 ++-
 drivers/base/bus.c                            | 43 +++++++++++++++++++
 include/linux/device.h                        | 19 +-------
 include/linux/device/driver.h                 |  2 +
 include/linux/panic.h                         |  3 +-
 include/trace/events/module.h                 |  3 +-
 kernel/panic.c                                |  3 +-
 tools/debugging/kernel-chktaint               |  8 ++++
 8 files changed, 66 insertions(+), 21 deletions(-)


base-commit: f5f84daefcd92d7a630066635ecea1433ed5eac7
-- 
2.47.3

[PATCH v3 1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted

[Uwe Kleine-König]

tainted-kernels.rst contains a small script to check which taint bits
are set in /proc/sys/kernel/tainted. Add one more loop iteration to also
handle the newly added TAINT_FORCED_BIND bit.

Also simplify by starting the loop at 0 and save substracting 1 for each
usage of the loop counter.

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 Documentation/admin-guide/tainted-kernels.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
index abbf5e3dd749..a208811ad525 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -74,7 +74,7 @@ a particular type of taint. It's best to leave that to the aforementioned
 script, but if you need something quick you can use this shell command to check
 which bits are set::
 
-	$ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
+	$ for i in $(seq 0 20); do echo $i $(($(cat /proc/sys/kernel/tainted)>>$i&1));done
 
 Table for decoding tainted state
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.47.3

[PATCH v3 2/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Uwe Kleine-König]

Commit fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when
userspace manually messes with devices and drivers") introduced a taint
for usage of bind/unbind sysfs files that manually trigger driver probe
and remove respectively.

For drivers that do their resource management correctly (which is also
needed for module unloading) bind and unbind for matching devices are
not critical operations. The thing that makes bind and unbind unsafe is
that drivers can be forced on devices that originally don't match using
driver_override. The result is that e.g. of_device_get_match_data()
returns NULL despite all .of_match_table entries having a non-NULL
.driver_data member which yields a NULL pointer exception for several
drivers. And given that after setting a driver_override a manual bind is
only one way a driver can be bound to an unexpected device, a separate
taint for such an override is justified.

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 Documentation/admin-guide/tainted-kernels.rst |  6 +++++-
 include/linux/device.h                        | 11 +++++++++--
 include/linux/panic.h                         |  3 ++-
 include/trace/events/module.h                 |  3 ++-
 kernel/panic.c                                |  3 ++-
 tools/debugging/kernel-chktaint               |  8 ++++++++
 6 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
index a208811ad525..9ccac96b1f75 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -74,7 +74,7 @@ a particular type of taint. It's best to leave that to the aforementioned
 script, but if you need something quick you can use this shell command to check
 which bits are set::
 
-	$ for i in $(seq 0 20); do echo $i $(($(cat /proc/sys/kernel/tainted)>>$i&1));done
+	$ for i in $(seq 0 21); do echo $i $(($(cat /proc/sys/kernel/tainted)>>$i&1));done
 
 Table for decoding tainted state
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -103,6 +103,7 @@ Bit  Log  Number   Reason that got the kernel tainted
  18  _/N   262144  an in-kernel test has been run
  19  _/J   524288  userspace used a mutating debug operation in fwctl
  20  _/Y  1048576  device was manually bound or unbound from a driver
+ 21  _/Z  2097152  a driver was forced on a non-matching device
 ===  ===  =======  ========================================================
 
 Note: The character ``_`` is representing a blank in this table to make reading
@@ -193,3 +194,6 @@ More detailed explanation for tainting
 
  20) ``Y`` If userspace wrote to the `bind` or `unbind` sysfs files and
      successfully bound or removed a device from a driver.
+
+ 21) ``Z`` If userspace wrote to a `driver_override` sysfs file opening the gate
+     for unexpected driver binding.
diff --git a/include/linux/device.h b/include/linux/device.h
index 879eb758b5ee..4dac5e09b74c 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);
+
+		return ret;
+	}
 	return -1;
 }
 
diff --git a/include/linux/panic.h b/include/linux/panic.h
index 23976b1dfdb6..e6e24d8afcf7 100644
--- a/include/linux/panic.h
+++ b/include/linux/panic.h
@@ -90,7 +90,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
 #define TAINT_TEST			18
 #define TAINT_FWCTL			19
 #define TAINT_FORCED_BIND		20
-#define TAINT_FLAGS_COUNT		21
+#define TAINT_DRIVER_OVERRIDE		21
+#define TAINT_FLAGS_COUNT		22
 #define TAINT_FLAGS_MAX			((1UL << TAINT_FLAGS_COUNT) - 1)
 
 struct taint_flag {
diff --git a/include/trace/events/module.h b/include/trace/events/module.h
index 19df3e39bba4..c7cdb1f53bc6 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" })
 
 TRACE_EVENT(module_load,
 
diff --git a/kernel/panic.c b/kernel/panic.c
index b824b68fcb08..a5d8743df496 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -826,6 +826,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
 	TAINT_FLAG(TEST,			'N', ' '),
 	TAINT_FLAG(FWCTL,			'J', ' '),
 	TAINT_FLAG(FORCED_BIND,			'Y', ' '),
+	TAINT_FLAG(DRIVER_OVERRIDE,		'Z', ' '),
 };
 
 #undef TAINT_FLAG
@@ -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 365 characters.
  */
 #define INIT_TAINT_BUF_MAX 370
 
diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
index d8628be37214..14d8febd6b16 100755
--- a/tools/debugging/kernel-chktaint
+++ b/tools/debugging/kernel-chktaint
@@ -219,6 +219,14 @@ else
 	addout "Y"
 	echo " * device was manually bound or unbound from a driver (#20)"
 fi
+
+T=`expr $T / 2`
+if [ `expr $T % 2` -eq 0 ]; then
+	addout " "
+else
+	addout "Z"
+	echo " * a driver was forced on a non-matching device (#21)"
+fi
 echo "Raw taint value as int/string: $taint/'$out'"
 
 # report on any tainted loadable modules
-- 
2.47.3

[PATCH v3 3/3] driver core: Disable driver overriding by default

[Uwe Kleine-König]

Driver overriding is useful only in a very limited set of situations
and then only with very few drivers that are designed to support that.

Disallow matching via driver_override unless the driver explicitly
allows it or the safe guard is disabled using the
"allow_driver_override" kernel parameter.

Implementation detail: device_match_driver_override() isn't a static
inline any more. It grew a certain complexity (e.g. a pr_info()) and so
was made a regular exported function.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/base/bus.c            | 43 +++++++++++++++++++++++++++++++++++
 include/linux/device.h        | 26 ++-------------------
 include/linux/device/driver.h |  2 ++
 3 files changed, 47 insertions(+), 24 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index c51ad96d4de4..d294c198ab0c 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -606,6 +606,49 @@ int bus_add_device(struct device *dev)
 	return error;
 }
 
+static int __read_mostly allow_driver_override;
+
+static int __init allow_driver_override_setup(char *str)
+{
+	allow_driver_override = 1;
+
+	return 1;
+}
+__setup("allow_driver_override", allow_driver_override_setup);
+
+/**
+ * device_match_driver_override() - Match a driver against the device's driver_override.
+ * @dev: device to check
+ * @drv: driver to match against
+ *
+ * Returns > 0 if a driver override is set and matches the given driver, 0 if a
+ * driver override is set but does not match, or < 0 if a driver override is not
+ * set at all.
+ */
+int device_match_driver_override(struct device *dev,
+				 const struct device_driver *drv)
+{
+	guard(spinlock)(&dev->driver_override.lock);
+	if (dev->driver_override.name) {
+		int ret = !strcmp(dev->driver_override.name, drv->name);
+
+		if (ret > 0) {
+			if (!allow_driver_override && !drv->support_driver_override) {
+				pr_info("Suppress driver override binding. Allow %ps to do overriding or boot with allow_driver_override on cmdline\n",
+					drv);
+				return -1;
+			}
+
+			add_taint_module(drv->owner,
+					 TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
+		}
+
+		return ret;
+	}
+	return -1;
+}
+EXPORT_SYMBOL_GPL(device_match_driver_override);
+
 /**
  * bus_probe_device - probe drivers for a new device
  * @dev: device to probe
diff --git a/include/linux/device.h b/include/linux/device.h
index 4dac5e09b74c..a142bf384f1e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -892,30 +892,8 @@ static inline bool device_has_driver_override(struct device *dev)
 	return !!dev->driver_override.name;
 }
 
-/**
- * device_match_driver_override() - Match a driver against the device's driver_override.
- * @dev: device to check
- * @drv: driver to match against
- *
- * Returns > 0 if a driver override is set and matches the given driver, 0 if a
- * driver override is set but does not match, or < 0 if a driver override is not
- * set at all.
- */
-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) {
-		int ret = !strcmp(dev->driver_override.name, drv->name);
-
-		if (ret > 0)
-			add_taint_module(drv->owner,
-					 TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
-
-		return ret;
-	}
-	return -1;
-}
+int device_match_driver_override(struct device *dev,
+				 const struct device_driver *drv);
 
 /**
  * device_iommu_mapped - Returns true when the device DMA is translated
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index 29fbc01ef06f..0153cfcbe1b9 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -56,6 +56,7 @@ enum probe_type {
  * @bus:	The bus which the device of this driver belongs to.
  * @owner:	The module owner.
  * @mod_name:	Used for built-in modules.
+ * @support_driver_override: driver_override only works if this is true.
  * @suppress_bind_attrs: Disables bind/unbind via sysfs.
  * @probe_type:	Type of the probe (synchronous or asynchronous) to use.
  * @of_match_table: The open firmware table.
@@ -104,6 +105,7 @@ struct device_driver {
 	struct module		*owner;
 	const char		*mod_name;	/* used for built-in modules */
 
+	bool support_driver_override;
 	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */
 	enum probe_type probe_type;
 
-- 
2.47.3

Re: [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Danilo Krummrich]

On Mon Sep 28, 2026 at 6:46 PM CEST, Uwe Kleine-König wrote:
> Note that different to Danilo's suggestion I don't differentiate between
> driver_overrides setup in userspace and those setup in kernel space.
> IMHO all are bad and there are alternatives for the legitimate cases.

I agree that the implementation - i.e. (ab)using driver override - the affected
subsystems have chosen is wrong.

But, there is a difference between picking the wrong implementation and being
semantically wrong to a point that we need to taint the kernel.

So, yes this should be cleaned up, but we should not taint the kernel for
otherwise correct code. Otherwise we could as well taint the kernel for every
other abuse of an API.

> I think applying this complete patch set and keeping fcbfaffee51a ("driver
> core: add TAINT_FORCED_BIND for when userspace manually messes with devices and
> drivers") is too much, so this series serves mainly as discussion ground for
> choosing a sane way to prevent fuzzing results of only mild interest and stop
> patch sets harding drivers for driver_override handling.
> My preference would be to revert (or drop) fcbfaffee51a and then only
> apply patch #3. Maybe also keep patch #2 to taint if
> "allow_driver_override" is provided.

Agreed, but as mentioned in [1], I think it is also reasonable to only keep
TAINT_FORCED_BIND for buses that do not support hotplug in the first place.

[1] https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/

Re: [PATCH v3 1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted

[Bradley Morgan]

On 28 September 2026 17:46:02 BST, "Uwe Kleine-König"
<u.kleine-koenig@baylibre.com> wrote:
>tainted-kernels.rst contains a small script to check which taint bits
>are set in /proc/sys/kernel/tainted. Add one more loop iteration to also
>handle the newly added TAINT_FORCED_BIND bit.
>
>Also simplify by starting the loop at 0 and save substracting 1 for each
>usage of the loop counter.
>
>Acked-by: Randy Dunlap <rdunlap@infradead.org>
>Tested-by: Randy Dunlap <rdunlap@infradead.org>
>Fixes: fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers")
>Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
>---
> Documentation/admin-guide/tainted-kernels.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
>index abbf5e3dd749..a208811ad525 100644
>--- a/Documentation/admin-guide/tainted-kernels.rst
>+++ b/Documentation/admin-guide/tainted-kernels.rst
>@@ -74,7 +74,7 @@ a particular type of taint. It's best to leave that to the aforementioned
> script, but if you need something quick you can use this shell command to
> check
> which bits are set::
> 
>-	$ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
>+	$ for i in $(seq 0 20); do echo $i $(($(cat /proc/sys/kernel/tainted)>>$i&1));done
> 
> Table for decoding tainted state
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Reviewed-by: Bradley Morgan <brads@mainlining.org>

Tested-by: Bradley Morgan <brads@mainlining.org> # Power10

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH v3 2/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Bradley Morgan]

On 28 September 2026 17:46:03 BST, "Uwe Kleine-König"
<u.kleine-koenig@baylibre.com> wrote:
>Commit fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when
>userspace manually messes with devices and drivers") introduced a taint
>for usage of bind/unbind sysfs files that manually trigger driver probe
>and remove respectively.
>
>For drivers that do their resource management correctly (which is also
>needed for module unloading) bind and unbind for matching devices are
>not critical operations. The thing that makes bind and unbind unsafe is
>that drivers can be forced on devices that originally don't match using
>driver_override. The result is that e.g. of_device_get_match_data()
>returns NULL despite all .of_match_table entries having a non-NULL
>.driver_data member which yields a NULL pointer exception for several
>drivers. And given that after setting a driver_override a manual bind is
>only one way a driver can be bound to an unexpected device, a separate
>taint for such an override is justified.
>
>Suggested-by: Danilo Krummrich <dakr@kernel.org>

From a quick scroll, I don't find anything wrong,

Reviewed-by: Bradley Morgan <brads@mainlining.org>


I just know this'll be a famous last words moment


>Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/
>Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
>---
> Documentation/admin-guide/tainted-kernels.rst |  6 +++++-
> include/linux/device.h                        | 11 +++++++++--
> include/linux/panic.h                         |  3 ++-
> include/trace/events/module.h                 |  3 ++-
> kernel/panic.c                                |  3 ++-
> tools/debugging/kernel-chktaint               |  8 ++++++++
> 6 files changed, 28 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
>index a208811ad525..9ccac96b1f75 100644
>--- a/Documentation/admin-guide/tainted-kernels.rst
>+++ b/Documentation/admin-guide/tainted-kernels.rst
>@@ -74,7 +74,7 @@ a particular type of taint. It's best to leave that to the aforementioned
> script, but if you need something quick you can use this shell command to
> check
> which bits are set::
> 
>-	$ for i in $(seq 0 20); do echo $i $(($(cat /proc/sys/kernel/tainted)>>$i&1));done
>+	$ for i in $(seq 0 21); do echo $i $(($(cat /proc/sys/kernel/tainted)>>$i&1));done
> 
> Table for decoding tainted state
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>@@ -103,6 +103,7 @@ Bit  Log  Number   Reason that got the kernel tainted
>  18  _/N   262144  an in-kernel test has been run
>  19  _/J   524288  userspace used a mutating debug operation in fwctl
>  20  _/Y  1048576  device was manually bound or unbound from a driver
>+ 21  _/Z  2097152  a driver was forced on a non-matching device
> ===  ===  ======= 
> ========================================================
> 
> Note: The character ``_`` is representing a blank in this table to make reading
>@@ -193,3 +194,6 @@ More detailed explanation for tainting
> 
>  20) ``Y`` If userspace wrote to the `bind` or `unbind` sysfs files and
>      successfully bound or removed a device from a driver.
>+
>+ 21) ``Z`` If userspace wrote to a `driver_override` sysfs file opening the gate
>+     for unexpected driver binding.
>diff --git a/include/linux/device.h b/include/linux/device.h
>index 879eb758b5ee..4dac5e09b74c 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);
>+
>+		return ret;
>+	}
> 	return -1;
> }
> 
>diff --git a/include/linux/panic.h b/include/linux/panic.h
>index 23976b1dfdb6..e6e24d8afcf7 100644
>--- a/include/linux/panic.h
>+++ b/include/linux/panic.h
>@@ -90,7 +90,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
> #define TAINT_TEST			18
> #define TAINT_FWCTL			19
> #define TAINT_FORCED_BIND		20
>-#define TAINT_FLAGS_COUNT		21
>+#define TAINT_DRIVER_OVERRIDE		21
>+#define TAINT_FLAGS_COUNT		22
> #define TAINT_FLAGS_MAX			((1UL << TAINT_FLAGS_COUNT) - 1)
> 
> struct taint_flag {
>diff --git a/include/trace/events/module.h b/include/trace/events/module.h
>index 19df3e39bba4..c7cdb1f53bc6 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" })
> 
> TRACE_EVENT(module_load,
> 
>diff --git a/kernel/panic.c b/kernel/panic.c
>index b824b68fcb08..a5d8743df496 100644
>--- a/kernel/panic.c
>+++ b/kernel/panic.c
>@@ -826,6 +826,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
> 	TAINT_FLAG(TEST,			'N', ' '),
> 	TAINT_FLAG(FWCTL,			'J', ' '),
> 	TAINT_FLAG(FORCED_BIND,			'Y', ' '),
>+	TAINT_FLAG(DRIVER_OVERRIDE,		'Z', ' '),
> };
> 
> #undef TAINT_FLAG
>@@ -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 365 characters.
>  */
> #define INIT_TAINT_BUF_MAX 370
> 
>diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
>index d8628be37214..14d8febd6b16 100755
>--- a/tools/debugging/kernel-chktaint
>+++ b/tools/debugging/kernel-chktaint
>@@ -219,6 +219,14 @@ else
> 	addout "Y"
> 	echo " * device was manually bound or unbound from a driver (#20)"
> fi
>+
>+T=`expr $T / 2`
>+if [ `expr $T % 2` -eq 0 ]; then
>+	addout " "
>+else
>+	addout "Z"
>+	echo " * a driver was forced on a non-matching device (#21)"
>+fi
> echo "Raw taint value as int/string: $taint/'$out'"
> 
> # report on any tainted loadable modules
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH v3 3/3] driver core: Disable driver overriding by default

[Bradley Morgan]

On 28 September 2026 17:46:04 BST, "Uwe Kleine-König"
<u.kleine-koenig@baylibre.com> wrote:
>Driver overriding is useful only in a very limited set of situations
>and then only with very few drivers that are designed to support that.
>
>Disallow matching via driver_override unless the driver explicitly
>allows it or the safe guard is disabled using the
>"allow_driver_override" kernel parameter.
>
>Implementation detail: device_match_driver_override() isn't a static
>inline any more. It grew a certain complexity (e.g. a pr_info()) and so
>was made a regular exported function.
>
>Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
>---
> drivers/base/bus.c            | 43 +++++++++++++++++++++++++++++++++++
> include/linux/device.h        | 26 ++-------------------
> include/linux/device/driver.h |  2 ++
> 3 files changed, 47 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/base/bus.c b/drivers/base/bus.c
>index c51ad96d4de4..d294c198ab0c 100644
>--- a/drivers/base/bus.c
>+++ b/drivers/base/bus.c
>@@ -606,6 +606,49 @@ int bus_add_device(struct device *dev)
> 	return error;
> }
> 
>+static int __read_mostly allow_driver_override;
>+
>+static int __init allow_driver_override_setup(char *str)
>+{
>+	allow_driver_override = 1;
>+
>+	return 1;
>+}
>+__setup("allow_driver_override", allow_driver_override_setup);
>+
>+/**
>+ * device_match_driver_override() - Match a driver against the device's driver_override.
>+ * @dev: device to check
>+ * @drv: driver to match against
>+ *
>+ * Returns > 0 if a driver override is set and matches the given driver, 0 if a
>+ * driver override is set but does not match, or < 0 if a driver override is not
>+ * set at all.
>+ */

Nice!

Reviewed-by: Bradley Morgan <brads@mainlining.org>

I mean, others may provide nits, but I'm rarely a nit guy

>+int device_match_driver_override(struct device *dev,
>+				 const struct device_driver *drv)
>+{
>+	guard(spinlock)(&dev->driver_override.lock);
>+	if (dev->driver_override.name) {
>+		int ret = !strcmp(dev->driver_override.name, drv->name);
>+
>+		if (ret > 0) {
>+			if (!allow_driver_override && !drv->support_driver_override) {
>+				pr_info("Suppress driver override binding. Allow %ps to do overriding or boot with allow_driver_override on cmdline\n",
>+					drv);
>+				return -1;
>+			}
>+
>+			add_taint_module(drv->owner,
>+					 TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
>+		}
>+
>+		return ret;
>+	}
>+	return -1;
>+}
>+EXPORT_SYMBOL_GPL(device_match_driver_override);
>+
> /**
>  * bus_probe_device - probe drivers for a new device
>  * @dev: device to probe
>diff --git a/include/linux/device.h b/include/linux/device.h
>index 4dac5e09b74c..a142bf384f1e 100644
>--- a/include/linux/device.h
>+++ b/include/linux/device.h
>@@ -892,30 +892,8 @@ static inline bool device_has_driver_override(struct device *dev)
> 	return !!dev->driver_override.name;
> }
> 
>-/**
>- * device_match_driver_override() - Match a driver against the device's driver_override.
>- * @dev: device to check
>- * @drv: driver to match against
>- *
>- * Returns > 0 if a driver override is set and matches the given driver, 0 if a
>- * driver override is set but does not match, or < 0 if a driver override is not
>- * set at all.
>- */
>-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) {
>-		int ret = !strcmp(dev->driver_override.name, drv->name);
>-
>-		if (ret > 0)
>-			add_taint_module(drv->owner,
>-					 TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
>-
>-		return ret;
>-	}
>-	return -1;
>-}
>+int device_match_driver_override(struct device *dev,
>+				 const struct device_driver *drv);
> 
> /**
>  * device_iommu_mapped - Returns true when the device DMA is translated
>diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
>index 29fbc01ef06f..0153cfcbe1b9 100644
>--- a/include/linux/device/driver.h
>+++ b/include/linux/device/driver.h
>@@ -56,6 +56,7 @@ enum probe_type {
>  * @bus:	The bus which the device of this driver belongs to.
>  * @owner:	The module owner.
>  * @mod_name:	Used for built-in modules.
>+ * @support_driver_override: driver_override only works if this is true.
>  * @suppress_bind_attrs: Disables bind/unbind via sysfs.
>  * @probe_type:	Type of the probe (synchronous or asynchronous) to use.
>  * @of_match_table: The open firmware table.
>@@ -104,6 +105,7 @@ struct device_driver {
> 	struct module		*owner;
> 	const char		*mod_name;	/* used for built-in modules */
> 
>+	bool support_driver_override;
> 	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */
> 	enum probe_type probe_type;
> 
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: (subset) [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Danilo Krummrich]

On Mon, 28 Sep 2026 18:46:01 +0200, Uwe Kleine-König wrote:
> [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

Applied, thanks!

  Branch: driver-core-testing
  Tree:   git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git

[1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted
      commit: f1850e443b0e

      [ Fix a typo in the commit message. - Danilo ]

The patch will appear in the next linux-next integration (typically within 24
hours on weekdays).

The patch is in the driver-core-testing branch and will be promoted to
driver-core-next after validation.

Re: (subset) [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Danilo Krummrich]

On Mon Sep 28, 2026 at 11:51 PM CEST, Danilo Krummrich wrote:
> On Mon, 28 Sep 2026 18:46:01 +0200, Uwe Kleine-König wrote:
>> [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
>
> Applied, thanks!
>
>   Branch: driver-core-testing
>   Tree:   git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
>
> [1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted
>       commit: f1850e443b0e
>
>       [ Fix a typo in the commit message. - Danilo ]
>
> The patch will appear in the next linux-next integration (typically within 24
> hours on weekdays).
>
> The patch is in the driver-core-testing branch and will be promoted to
> driver-core-next after validation.

I've picked this up, as this fix is independent from the rest of the series.

Thanks,
Danilo

Re: (subset) [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Hello Danilo,

On Mon, Sep 28, 2026 at 11:53:03PM +0200, Danilo Krummrich wrote:
> On Mon Sep 28, 2026 at 11:51 PM CEST, Danilo Krummrich wrote:
> > On Mon, 28 Sep 2026 18:46:01 +0200, Uwe Kleine-König wrote:
> >> [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
> >
> > Applied, thanks!
> >
> >   Branch: driver-core-testing
> >   Tree:   git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
> >
> > [1/3] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted
> >       commit: f1850e443b0e
> >
> >       [ Fix a typo in the commit message. - Danilo ]

Oh thanks.

> > The patch will appear in the next linux-next integration (typically within 24
> > hours on weekdays).
> >
> > The patch is in the driver-core-testing branch and will be promoted to
> > driver-core-next after validation.
> 
> I've picked this up, as this fix is independent from the rest of the series.

That's great, I will make sure to base the next respin on top of that.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Mon, Sep 28, 2026 at 07:15:12PM +0200, Danilo Krummrich wrote:
> On Mon Sep 28, 2026 at 6:46 PM CEST, Uwe Kleine-König wrote:
> > Note that different to Danilo's suggestion I don't differentiate between
> > driver_overrides setup in userspace and those setup in kernel space.
> > IMHO all are bad and there are alternatives for the legitimate cases.
> 
> I agree that the implementation - i.e. (ab)using driver override - the affected
> subsystems have chosen is wrong.
> 
> But, there is a difference between picking the wrong implementation and being
> semantically wrong to a point that we need to taint the kernel.
> 
> So, yes this should be cleaned up, but we should not taint the kernel for
> otherwise correct code. Otherwise we could as well taint the kernel for every
> other abuse of an API.

My position on that is: Do the global change now and help the subsystems
to clean up the mess. In my experice waiting with changes until all
affected parties are smooth with it is a recipe for failure.

> > I think applying this complete patch set and keeping fcbfaffee51a ("driver
> > core: add TAINT_FORCED_BIND for when userspace manually messes with devices and
> > drivers") is too much, so this series serves mainly as discussion ground for
> > choosing a sane way to prevent fuzzing results of only mild interest and stop
> > patch sets harding drivers for driver_override handling.
> > My preference would be to revert (or drop) fcbfaffee51a and then only
> > apply patch #3. Maybe also keep patch #2 to taint if
> > "allow_driver_override" is provided.
> 
> Agreed, but as mentioned in [1], I think it is also reasonable to only keep
> TAINT_FORCED_BIND for buses that do not support hotplug in the first place.
> 
> [1] https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/

Fine for me, that would mean to apply the whole series and restrict
TAINT_FORCED_BIND to "static" busses.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 0/3] Add TAINT_DRIVER_OVERRIDE for usage of driver_override

[Danilo Krummrich]

On Tue Sep 29, 2026 at 7:53 AM CEST, Uwe Kleine-König wrote:
> On Mon, Sep 28, 2026 at 07:15:12PM +0200, Danilo Krummrich wrote:
>> On Mon Sep 28, 2026 at 6:46 PM CEST, Uwe Kleine-König wrote:
>> > Note that different to Danilo's suggestion I don't differentiate between
>> > driver_overrides setup in userspace and those setup in kernel space.
>> > IMHO all are bad and there are alternatives for the legitimate cases.
>> 
>> I agree that the implementation - i.e. (ab)using driver override - the affected
>> subsystems have chosen is wrong.
>> 
>> But, there is a difference between picking the wrong implementation and being
>> semantically wrong to a point that we need to taint the kernel.
>> 
>> So, yes this should be cleaned up, but we should not taint the kernel for
>> otherwise correct code. Otherwise we could as well taint the kernel for every
>> other abuse of an API.
>
> My position on that is: Do the global change now and help the subsystems
> to clean up the mess. In my experice waiting with changes until all
> affected parties are smooth with it is a recipe for failure.

I do see an advantage in having the taint in match() rather than store(), so I
prefer that too.

But again, I do not feel comfortable to taint the kernel for something that does
use the wrong API but otherwise behaves correctly and shouldn't taint the kernel
at all.

We have six users of device_set_driver_override() outside of a userspace
reachable scope. Did you have a look at how hard they are to fix? Do you plan to
provide patches?

>> > I think applying this complete patch set and keeping fcbfaffee51a ("driver
>> > core: add TAINT_FORCED_BIND for when userspace manually messes with devices and
>> > drivers") is too much, so this series serves mainly as discussion ground for
>> > choosing a sane way to prevent fuzzing results of only mild interest and stop
>> > patch sets harding drivers for driver_override handling.
>> > My preference would be to revert (or drop) fcbfaffee51a and then only
>> > apply patch #3. Maybe also keep patch #2 to taint if
>> > "allow_driver_override" is provided.
>> 
>> Agreed, but as mentioned in [1], I think it is also reasonable to only keep
>> TAINT_FORCED_BIND for buses that do not support hotplug in the first place.
>> 
>> [1] https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/
>
> Fine for me, that would mean to apply the whole series and restrict
> TAINT_FORCED_BIND to "static" busses.

That sounds fine to me.