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

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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    66498c75b4f8 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1253719e580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3e64b1bf01d830ed
dashboard link: https://syzkaller.appspot.com/bug?extid=1a01783ea233350598b5
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
userspace arch: i386
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17491979580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-66498c75.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/5ce4685e13ba/vmlinux-66498c75.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6a32d8e997a7/bzImage-66498c75.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1a01783ea233350598b5@syzkaller.appspotmail.com

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 UID: 0 PID: 5912 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:wcove_typec_probe+0xdb/0x780 drivers/usb/typec/tcpm/wcove.c:621
Code: 48 c1 ea 03 80 3c 02 00 0f 85 af 05 00 00 48 8d 7d 08 4d 89 af 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7f 05 00 00 49 8d bf 90 00 00 00 48 8b 6d 08 48
RSP: 0018:ffffc90002f6faf8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8880226c1000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000008
RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
R10: ffff888014243883 R11: 000000000000001f R12: ffffffff904a7ea8
R13: ffff8880226c1010 R14: ffff8880142438c0 R15: ffff888014243838
FS:  0000000000000000(0000) GS:ffff888096982000(0063) knlGS:00000000f67e5b40
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000032e24008 CR3: 000000004e2f1000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 platform_probe+0x106/0x1d0 drivers/base/platform.c:1507
 call_driver_probe drivers/base/dd.c:628 [inline]
 really_probe+0x241/0xa60 drivers/base/dd.c:706
 __driver_probe_device+0x210/0x460 drivers/base/dd.c:868
 device_driver_attach+0xd1/0x220 drivers/base/dd.c:1203
 bind_store+0xf4/0x190 drivers/base/bus.c:267
 drv_attr_store+0x74/0xb0 drivers/base/bus.c:125
 sysfs_kf_write+0xf2/0x150 fs/sysfs/file.c:145
 kernfs_fop_write_iter+0x3e0/0x5f0 fs/kernfs/file.c:345
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x6af/0x1050 fs/read_write.c:687
 ksys_write+0x12a/0x250 fs/read_write.c:739
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:79 [inline]
 __do_fast_syscall_32+0x13a/0x8b0 arch/x86/entry/syscall_32.c:291
 do_fast_syscall_32+0x32/0x70 arch/x86/entry/syscall_32.c:316
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
RIP: 0023:0xf6feefec
Code: Unable to access opcode bytes at 0xf6feefc2.
RSP: 002b:00000000f67e550c EFLAGS: 00000292 ORIG_RAX: 0000000000000004
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000080000400
RDX: 0000000000000007 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:wcove_typec_probe+0xdb/0x780 drivers/usb/typec/tcpm/wcove.c:621
Code: 48 c1 ea 03 80 3c 02 00 0f 85 af 05 00 00 48 8d 7d 08 4d 89 af 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7f 05 00 00 49 8d bf 90 00 00 00 48 8b 6d 08 48
RSP: 0018:ffffc90002f6faf8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8880226c1000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000008
RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
R10: ffff888014243883 R11: 000000000000001f R12: ffffffff904a7ea8
R13: ffff8880226c1010 R14: ffff8880142438c0 R15: ffff888014243838
FS:  0000000000000000(0000) GS:ffff888096a82000(0063) knlGS:00000000f67e5b40
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00007f45dd833708 CR3: 000000004e2f1000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess):
   0:	48 c1 ea 03          	shr    $0x3,%rdx
   4:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   8:	0f 85 af 05 00 00    	jne    0x5bd
   e:	48 8d 7d 08          	lea    0x8(%rbp),%rdi
  12:	4d 89 af 88 00 00 00 	mov    %r13,0x88(%r15)
  19:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  20:	fc ff df
  23:	48 89 fa             	mov    %rdi,%rdx
  26:	48 c1 ea 03          	shr    $0x3,%rdx
* 2a:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
  2e:	0f 85 7f 05 00 00    	jne    0x5b3
  34:	49 8d bf 90 00 00 00 	lea    0x90(%r15),%rdi
  3b:	48 8b 6d 08          	mov    0x8(%rbp),%rbp
  3f:	48                   	rex.W


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

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

[Greg KH]

On Mon, Aug 24, 2026 at 08:43:40PM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    66498c75b4f8 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1253719e580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=3e64b1bf01d830ed
> dashboard link: https://syzkaller.appspot.com/bug?extid=1a01783ea233350598b5
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> userspace arch: i386
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17491979580000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-66498c75.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/5ce4685e13ba/vmlinux-66498c75.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/6a32d8e997a7/bzImage-66498c75.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+1a01783ea233350598b5@syzkaller.appspotmail.com
> 
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> CPU: 0 UID: 0 PID: 5912 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:wcove_typec_probe+0xdb/0x780 drivers/usb/typec/tcpm/wcove.c:621
> Code: 48 c1 ea 03 80 3c 02 00 0f 85 af 05 00 00 48 8d 7d 08 4d 89 af 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7f 05 00 00 49 8d bf 90 00 00 00 48 8b 6d 08 48
> RSP: 0018:ffffc90002f6faf8 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: ffff8880226c1000 RCX: 0000000000000000
> RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000008
> RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
> R10: ffff888014243883 R11: 000000000000001f R12: ffffffff904a7ea8
> R13: ffff8880226c1010 R14: ffff8880142438c0 R15: ffff888014243838
> FS:  0000000000000000(0000) GS:ffff888096982000(0063) knlGS:00000000f67e5b40
> CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> CR2: 0000000032e24008 CR3: 000000004e2f1000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  platform_probe+0x106/0x1d0 drivers/base/platform.c:1507
>  call_driver_probe drivers/base/dd.c:628 [inline]
>  really_probe+0x241/0xa60 drivers/base/dd.c:706
>  __driver_probe_device+0x210/0x460 drivers/base/dd.c:868
>  device_driver_attach+0xd1/0x220 drivers/base/dd.c:1203
>  bind_store+0xf4/0x190 drivers/base/bus.c:267

Please do not think that this is a valid path for syzbot to be
fuzzing...

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

[Jeffin Philip]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 155 bytes --]

On Tue, Aug 25, 2026, 10:42 AM, Greg KH wrote:
>Please do not think that this is a valid path for syzbot to be
>fuzzing...

Understood

Thanks,
Jeffin.

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

[Aleksandr Nogikh]

Hi Greg,

On Tue, Aug 25, 2026 at 7:12 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Aug 24, 2026 at 08:43:40PM -0700, syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit:    66498c75b4f8 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1253719e580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=3e64b1bf01d830ed
> > dashboard link: https://syzkaller.appspot.com/bug?extid=1a01783ea233350598b5
> > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > userspace arch: i386
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17491979580000
> >
> > Downloadable assets:
> > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-66498c75.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/5ce4685e13ba/vmlinux-66498c75.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/6a32d8e997a7/bzImage-66498c75.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+1a01783ea233350598b5@syzkaller.appspotmail.com
> >
> > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
> > KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> > CPU: 0 UID: 0 PID: 5912 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > RIP: 0010:wcove_typec_probe+0xdb/0x780 drivers/usb/typec/tcpm/wcove.c:621
> > Code: 48 c1 ea 03 80 3c 02 00 0f 85 af 05 00 00 48 8d 7d 08 4d 89 af 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7f 05 00 00 49 8d bf 90 00 00 00 48 8b 6d 08 48
> > RSP: 0018:ffffc90002f6faf8 EFLAGS: 00010202
> > RAX: dffffc0000000000 RBX: ffff8880226c1000 RCX: 0000000000000000
> > RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000008
> > RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
> > R10: ffff888014243883 R11: 000000000000001f R12: ffffffff904a7ea8
> > R13: ffff8880226c1010 R14: ffff8880142438c0 R15: ffff888014243838
> > FS:  0000000000000000(0000) GS:ffff888096982000(0063) knlGS:00000000f67e5b40
> > CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> > CR2: 0000000032e24008 CR3: 000000004e2f1000 CR4: 0000000000352ef0
> > Call Trace:
> >  <TASK>
> >  platform_probe+0x106/0x1d0 drivers/base/platform.c:1507
> >  call_driver_probe drivers/base/dd.c:628 [inline]
> >  really_probe+0x241/0xa60 drivers/base/dd.c:706
> >  __driver_probe_device+0x210/0x460 drivers/base/dd.c:868
> >  device_driver_attach+0xd1/0x220 drivers/base/dd.c:1203
> >  bind_store+0xf4/0x190 drivers/base/bus.c:267
>
> 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?

-- 
Aleksandr

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

[Greg KH]

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@linuxfoundation.org> wrote:
> >
> > On Mon, Aug 24, 2026 at 08:43:40PM -0700, syzbot wrote:
> > > syzbot has found a reproducer for the following issue on:
> > >
> > > HEAD commit:    66498c75b4f8 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1253719e580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=3e64b1bf01d830ed
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=1a01783ea233350598b5
> > > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > > userspace arch: i386
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17491979580000
> > >
> > > Downloadable assets:
> > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-66498c75.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/5ce4685e13ba/vmlinux-66498c75.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/6a32d8e997a7/bzImage-66498c75.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+1a01783ea233350598b5@syzkaller.appspotmail.com
> > >
> > > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
> > > KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> > > CPU: 0 UID: 0 PID: 5912 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
> > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > > RIP: 0010:wcove_typec_probe+0xdb/0x780 drivers/usb/typec/tcpm/wcove.c:621
> > > Code: 48 c1 ea 03 80 3c 02 00 0f 85 af 05 00 00 48 8d 7d 08 4d 89 af 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7f 05 00 00 49 8d bf 90 00 00 00 48 8b 6d 08 48
> > > RSP: 0018:ffffc90002f6faf8 EFLAGS: 00010202
> > > RAX: dffffc0000000000 RBX: ffff8880226c1000 RCX: 0000000000000000
> > > RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000008
> > > RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
> > > R10: ffff888014243883 R11: 000000000000001f R12: ffffffff904a7ea8
> > > R13: ffff8880226c1010 R14: ffff8880142438c0 R15: ffff888014243838
> > > FS:  0000000000000000(0000) GS:ffff888096982000(0063) knlGS:00000000f67e5b40
> > > CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> > > CR2: 0000000032e24008 CR3: 000000004e2f1000 CR4: 0000000000352ef0
> > > Call Trace:
> > >  <TASK>
> > >  platform_probe+0x106/0x1d0 drivers/base/platform.c:1507
> > >  call_driver_probe drivers/base/dd.c:628 [inline]
> > >  really_probe+0x241/0xa60 drivers/base/dd.c:706
> > >  __driver_probe_device+0x210/0x460 drivers/base/dd.c:868
> > >  device_driver_attach+0xd1/0x220 drivers/base/dd.c:1203
> > >  bind_store+0xf4/0x190 drivers/base/bus.c:267
> >
> > 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,

greg k-h

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

[Aleksandr Nogikh]

On Tue, Aug 25, 2026 at 11:07 AM Greg KH <gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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

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@linuxfoundation.org> 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@linuxfoundation.org> 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@linuxfoundation.org

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

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

[Aleksandr Nogikh]

On Wed, Aug 26, 2026 at 4:11 PM Greg KH <gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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@linuxfoundation.org> 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@linuxfoundation.org
>
> Is that sufficient?

Hmm, if we set `panic_on_taint=` with TAINT_FORCED_BIND and ignore
such crashes, I think it could work, yes.

>
> If not, no, I really don't want to make a kernel config option just for
> this type of thing.
>
> thanks,
>
> greg k-h

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

[Greg KH]

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@linuxfoundation.org> 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@linuxfoundation.org> 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@linuxfoundation.org> 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@linuxfoundation.org
> >
> > 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

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

[Aleksandr Nogikh]

On Wed, Aug 26, 2026 at 5:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> 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@linuxfoundation.org> wrote:
> > >
> > > On Wed, Aug 26, 2026 at 03:26:23PM +0200, Aleksandr Nogikh wrote:
< ... >
> > > >
> > > > 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@linuxfoundation.org
> > >
> > > 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.

Thanks!

FYI, I've just merged a mitigation into syzkaller:
https://github.com/google/syzkaller/commit/c53a1b9ca227. It should
prevent syzkaller from touching /bind, /unbind, etc., at least until
it finds a workaround.

Some more such bug reports are already in the reporting pipeline and
may still reach LKML, but new ones should stop appearing.

-- 
Aleksandr

>
> greg k-h