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

Hi Greg,

On Tue, Aug 25, 2026 at 7:12 AM Greg KH <[email protected]> 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: [email protected]
> >
> > 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