Re: [PATCH v4 0/3] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Oct 27, 2026 at 07:03:00AM +0100, Michal Pecio wrote:
> > And as said before, that's a horrid hack and one that is breaking
> > things today in all sorts of ways, which is why the taint was added.
> 
> Are you aware of bind/unbind breaking things for PCI specifically?

Yes, we had reports of this happening for many PCI drivers where unbind
would be triggered and a random pci device would then be "bound" to the
driver and the kernel would crash.  See the zillion syzbot reports of a
few months ago, which caused all of this to happen.

> Without also involving 'driver_override' or 'new_id'? Everyone agrees
> that these APIs used for anything other than pci-stub or vfio are foot
> guns. But your patch targets something different.

Yes, driver_override and/or new_id was being used for most of these, BUT
unbind for other busses was also causing problems (specifically many
platform drivers.)

> We can even bind PCI drivers to wrong devices *without* using bind and
> hence, I presume but don't care to test, without tripping this taint.
> 
> > If you wish to override the kernel, then great, a taint flag is added
> > and all is fine.  All this means is that now developers know what you
> > did and can decide to ignore your bug report or not.  No functionality
> > changed at all.
> 
> I believe people pointed out that it's a functional change for users of
> panic_on_taint who also use bind without being idiots.
> 
> Does this taint even solve a "real" problem? Those bug reports weren't
> coming from users, they were coming from "abusers" like syzbot looking
> for trouble. They were quite obvious even without a taint message.

They were not obvious at all, see the patches that many maintainers
"accidentally" took to fix a bug that really wasn't a bug at all.  This
was forcing additional code into all drivers for no good reason, hence
the taint flag.

Let me reconsider this and think about just doing it for the additional
id and allowing busses to trip it when their unbind is hit for busses
that should not be normally handling unbind (i.e. platform devices.)

thanks,

greg k-h