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/[email protected]/
