[BUG] usb: dummy_hcd: general protection fault in set_link_state on unbind

[BUG] usb: dummy_hcd: general protection fault in set_link_state on unbind

[CJ]

Hi,


I am reporting a general protection fault in the dummy_hcd link-state handling,
triggered by a syzkaller USB reproducer.  The issue is reproducible with HEAD
commit cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux 7.3.0-rc1).


The reproducer connects a synthetic HID USB device through dummy_hcd and then
unbinds the dummy_hcd.0 platform device by writing its name to the driver's
unbind attribute.  The failure happens during the teardown that follows.


The console shows a general protection fault for the non-canonical address
0xdffffc0000000000 with a KASAN null-ptr-deref in the range [0x0-0x7], and RIP
in set_link_state.  The path reaches it through the gadget disconnect and
unbind sequence (usb_gadget_disconnect_locked -> gadget_unbind_driver ->
device_remove) while the dummy UDC is being removed.


One possible cause is that the link-state helper runs on a UDC whose private
data has already been released by the unbind, so it dereferences a NULL
pointer.  This looks like an ordering/lifetime problem between the platform
driver's remove path and the gadget disconnect path.  I note that d5e5cd3654d2
fixed a related giveback lifetime issue in this file but does not cover
set_link_state.  I am reporting the fault and the path as observed.


This appears to be a recurrence of the syzbot issue whose external id is
83e39b821587064bd7a3.  It remains reproducible on v7.3-rc1.


Reproducer:


syz reproducer:
syz_usb_connect$hid(0x3, 0x36, &(0x7f0000000140)=ANY=[@ANYBLOB="1201000000000010d804dd00000000000001090224000100000000090400000103000000092105000001220500090581030002"], 0x0)
mkdirat(0xffffffffffffff9c, &(0x7f0000000000)='./mysys\x00', 0x1ff)
mount(0x0, &(0x7f0000000080)='./mysys\x00', &(0x7f00000000c0)='sysfs\x00', 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000100)='./mysys/bus/platform/drivers/dummy_hcd/unbind\x00', 0x1, 0x0)
write(r0, &(0x7f0000000200)='dummy_hcd.0\x00', 0xb)


console output: https://pastebin.com/raw/1CNVfMHw
kernel config: https://pastebin.com/raw/19YvTSEp


Kernel:


HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
           e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)


Let me know if you need more details or testing.


Best regards,
Changjian

Re: [BUG] usb: dummy_hcd: general protection fault in set_link_state on unbind

[Greg KH]

On Thu, Sep 17, 2026 at 04:00:00PM +0800, CJ wrote:
> 
> Hi,
> 
> 
> I am reporting a general protection fault in the dummy_hcd link-state handling,
> triggered by a syzkaller USB reproducer.  The issue is reproducible with HEAD
> commit cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux 7.3.0-rc1).
> 
> 
> The reproducer connects a synthetic HID USB device through dummy_hcd and then
> unbinds the dummy_hcd.0 platform device by writing its name to the driver's
> unbind attribute.  The failure happens during the teardown that follows.
> 
> 
> The console shows a general protection fault for the non-canonical address
> 0xdffffc0000000000 with a KASAN null-ptr-deref in the range [0x0-0x7], and RIP
> in set_link_state.  The path reaches it through the gadget disconnect and
> unbind sequence (usb_gadget_disconnect_locked -> gadget_unbind_driver ->
> device_remove) while the dummy UDC is being removed.
> 
> 
> One possible cause is that the link-state helper runs on a UDC whose private
> data has already been released by the unbind, so it dereferences a NULL
> pointer.  This looks like an ordering/lifetime problem between the platform
> driver's remove path and the gadget disconnect path.  I note that d5e5cd3654d2
> fixed a related giveback lifetime issue in this file but does not cover
> set_link_state.  I am reporting the fault and the path as observed.
> 
> 
> This appears to be a recurrence of the syzbot issue whose external id is
> 83e39b821587064bd7a3.  It remains reproducible on v7.3-rc1.
> 
> 
> Reproducer:
> 
> 
> syz reproducer:
> syz_usb_connect$hid(0x3, 0x36, &(0x7f0000000140)=ANY=[@ANYBLOB="1201000000000010d804dd00000000000001090224000100000000090400000103000000092105000001220500090581030002"], 0x0)
> mkdirat(0xffffffffffffff9c, &(0x7f0000000000)='./mysys\x00', 0x1ff)
> mount(0x0, &(0x7f0000000080)='./mysys\x00', &(0x7f00000000c0)='sysfs\x00', 0x0, 0x0)
> r0 = openat(0xffffffffffffff9c, &(0x7f0000000100)='./mysys/bus/platform/drivers/dummy_hcd/unbind\x00', 0x1, 0x0)
> write(r0, &(0x7f0000000200)='dummy_hcd.0\x00', 0xb)
> 
> 
> console output: https://pastebin.com/raw/1CNVfMHw
> kernel config: https://pastebin.com/raw/19YvTSEp
> 
> 
> Kernel:
> 
> 
> HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
> git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
>            e5e04726cdd043e309677071ab1b65a4b18f422b
> kernel version: 7.3.0-rc1 #1 PREEMPT(full)
> tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)
> 
> 
> Let me know if you need more details or testing.

As you have a reproducer, why not make up a patch to fix it as you have
a way to test this?  That's the best way to get things resolved given
our HUGE pending patch queue to work through.

thanks,

greg k-h

Re: [BUG] usb: dummy_hcd: general protection fault in set_link_state on unbind

[Alan Stern]

On Thu, Sep 17, 2026 at 04:00:00PM +0800, CJ wrote:
> 
> Hi,
> 
> 
> I am reporting a general protection fault in the dummy_hcd link-state handling,
> triggered by a syzkaller USB reproducer.  The issue is reproducible with HEAD
> commit cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux 7.3.0-rc1).
> 
> 
> The reproducer connects a synthetic HID USB device through dummy_hcd and then
> unbinds the dummy_hcd.0 platform device by writing its name to the driver's
> unbind attribute.  The failure happens during the teardown that follows.

This patch:

https://lore.kernel.org/linux-usb/18ec3122-7566-49e5-9964-1028857405b1@mail.kernel.org/

was submitted at the end of July but it hasn't been merged yet.  Does it 
fix the problem?

Alan Stern