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

[Aleksandr Nogikh]

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.

Best regards,
Aleksandr

>
> thanks,
>
> greg k-h