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

From: Greg KH

Date: Wed Aug 26 2026 - 11:26:08 EST


On Wed, Aug 26, 2026 at 04:32:28PM +0200, Aleksandr Nogikh wrote:
> On Wed, Aug 26, 2026 at 4:11 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > 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?
>
> Hmm, if we set `panic_on_taint=` with TAINT_FORCED_BIND and ignore
> such crashes, I think it could work, yes.

Great, thanks for confirming. I'll add that to the changelog just to
highlight how this can be used.

greg k-h