Re: [syzbot] [usb?] general protection fault in wcove_typec_probe

[Greg KH]

On Wed, Aug 26, 2026 at 03:26:23PM +0200, Aleksandr Nogikh wrote:
> On Tue, Aug 25, 2026 at 11:07 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Aug 25, 2026 at 11:04:54AM +0200, Aleksandr Nogikh wrote:
> > > Hi Greg,
> > >
> > > On Tue, Aug 25, 2026 at 7:12 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> < .. >
> > > >
> > > > Please do not think that this is a valid path for syzbot to be
> > > > fuzzing...
> > > >
> > >
> > > Can you please elaborate on this?
> > > Do you mean driver binding sysfs interface in general or something
> > > more specific?
> >
> > That is the specific thing, don't have syzbot do random bind/unbind
> > calls, having it attempt to bind any random driver to any random
> > hardware device.  That's not how bind/unbind is supposed to work at all,
> > it's for developers who "know what they are doing" and you get to keep
> > the broken system if you mess it up.
> >
> > Same for unbind.
> >
> > This is a root-only api for that reason.
> 
> Thanks for clarifying!
> 
> Some context from the syzkaller side:
> Restricting the fuzzer is always tricky, especially when the
> problematic operation is just opening a file and writing to it.
> 
> We normally constrain openat to:
> 1) An allowlist of safe absolute paths (so it won't open /dev/mem,
> etc.), blocking any other path starting with '/'.
> 2) Relative paths under CWD (so we can still fuzz normal file operations).
> 
> Here the problem is that one can mount sysfs under CWD, which leaves
> syzkaller full access to everything inside it.
> 
> Tightening the access to /bind, /unbind, /driver_override sounds
> reasonable, but trying to catch all workarounds purely in userspace
> (e.g., creating symlinks to these paths before opening them) will
> easily turn into a whack-a-mole.
> 
> Would you be open to adding some kernel config option or a boot
> parameter to disable manual sysfs driver bind/unbind and
> driver_override? We had a similar problem with writing to a block
> device while a filesystem was being mounted, which was perfectly
> solved by CONFIG_BLK_DEV_WRITE_MOUNTED.

I've submitted a patch to taint the kernel if these files are written
to, so that should "catch" syzbot and let you know to ignore these
reports if it runs into them:
	https://lore.kernel.org/r/20260826-bind_taint-v1-0-52b05f4a965c@xxxxxxxxxxxxxxxxxxx

Is that sufficient?

If not, no, I really don't want to make a kernel config option just for
this type of thing.

thanks,

greg k-h