Dear Linux Developers for F_printer,
We encountered "WARNING in usb_ep_queue" when testing the f_printer driver with
Syzkaller and our generated specifications.
I attached the report and C/syz reproducers for this crash.
```
------------[ cut here ]------------
WARNING: CPU: 1 PID: 10395 at drivers/usb/gadget/udc/core.c:295
usb_ep_queue+0xa0/0x300 linux/drivers/usb/gadget/udc/core.c:295
Modules linked in:
CPU: 1 PID: 10395 Comm: syz-executor364 Not tainted 6.6.0-gd2f51b3516da #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:usb_ep_queue+0xa0/0x300 linux/drivers/usb/gadget/udc/core.c:295
Code: 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 31 02 00 00 0f b6
5d 35 31 ff 89 de e8 da 51 08 fa 84 db 74 11 e8 01 56 08 fa 90 <0f> 0b
90 41 bd 94 ff ff ff eb 56 e8 f0 55 08 fa 48 8d 7d 10 48 b8
RSP: 0018:ffffc900075cfc00 EFLAGS: 00010093
RAX: 0000000000000000 RBX: 0000000000000081 RCX: ffffffff8786e5a6
RDX: ffff88801cd59e00 RSI: ffffffff8786e5af RDI: 0000000000000001
RBP: ffff8880173d80e0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000081 R11: 0000000000000000 R12: ffff888019236e10
R13: 0000000000000820 R14: 0000000000000000 R15: ffff888019236e58
FS: 000055555591d3c0(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020c55000 CR3: 0000000024d03000 CR4: 0000000000350ef0
Call Trace:
<TASK>
printer_write+0x650/0xf30 linux/drivers/usb/gadget/function/f_printer.c:669
vfs_write+0x2ae/0xd80 linux/fs/read_write.c:582
ksys_write+0x127/0x250 linux/fs/read_write.c:637
do_syscall_x64 linux/arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x40/0x110 linux/arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f1c4a60e3bd
Code: c3 e8 87 20 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd3d68a858 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000000f4240 RCX: 00007f1c4a60e3bd
RDX: 000000000000004f RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007f1c4a663cd5 R09: 00007f1c4a663cd5
R10: 00237265746e6972 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffd3d68aab8 R14: 00007ffd3d68a880 R15: 00007ffd3d68a870
</TASK>
```
It seems that the `WARN_ON_ONCE(!ep->enabled && ep->address)` in
usb_ep_queue (https://elixir.bootlin.com/linux/v6.7/source/drivers/usb/gadget/udc/core.c#L290),
which is invoked by `printer_write`
(https://elixir.bootlin.com/linux/v6.7/source/drivers/usb/gadget/function/f_printer.c#L669).
If you have any questions or require more information, please feel
free to contact us.
Reported-by: Chenyuan Yang <[email protected]>
Best,
Chenyuan
On Fri, Feb 02, 2024 at 12:59:31PM -0600, Chenyuan Yang wrote:
> Dear Linux Developers for F_printer,
>
> We encountered "WARNING in usb_ep_queue" when testing the f_printer driver with
> Syzkaller and our generated specifications.
>
> I attached the report and C/syz reproducers for this crash.
>
> ```
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 10395 at drivers/usb/gadget/udc/core.c:295
> usb_ep_queue+0xa0/0x300 linux/drivers/usb/gadget/udc/core.c:295
> Modules linked in:
> CPU: 1 PID: 10395 Comm: syz-executor364 Not tainted 6.6.0-gd2f51b3516da #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:usb_ep_queue+0xa0/0x300 linux/drivers/usb/gadget/udc/core.c:295
> Code: 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 31 02 00 00 0f b6
> 5d 35 31 ff 89 de e8 da 51 08 fa 84 db 74 11 e8 01 56 08 fa 90 <0f> 0b
> 90 41 bd 94 ff ff ff eb 56 e8 f0 55 08 fa 48 8d 7d 10 48 b8
> RSP: 0018:ffffc900075cfc00 EFLAGS: 00010093
> RAX: 0000000000000000 RBX: 0000000000000081 RCX: ffffffff8786e5a6
> RDX: ffff88801cd59e00 RSI: ffffffff8786e5af RDI: 0000000000000001
> RBP: ffff8880173d80e0 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000081 R11: 0000000000000000 R12: ffff888019236e10
> R13: 0000000000000820 R14: 0000000000000000 R15: ffff888019236e58
> FS: 000055555591d3c0(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020c55000 CR3: 0000000024d03000 CR4: 0000000000350ef0
> Call Trace:
> <TASK>
> printer_write+0x650/0xf30 linux/drivers/usb/gadget/function/f_printer.c:669
> vfs_write+0x2ae/0xd80 linux/fs/read_write.c:582
> ksys_write+0x127/0x250 linux/fs/read_write.c:637
> do_syscall_x64 linux/arch/x86/entry/common.c:51 [inline]
> do_syscall_64+0x40/0x110 linux/arch/x86/entry/common.c:82
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
> RIP: 0033:0x7f1c4a60e3bd
> Code: c3 e8 87 20 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffd3d68a858 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00000000000f4240 RCX: 00007f1c4a60e3bd
> RDX: 000000000000004f RSI: 00000000200000c0 RDI: 0000000000000003
> RBP: 0000000000000000 R08: 00007f1c4a663cd5 R09: 00007f1c4a663cd5
> R10: 00237265746e6972 R11: 0000000000000246 R12: 0000000000000001
> R13: 00007ffd3d68aab8 R14: 00007ffd3d68a880 R15: 00007ffd3d68a870
> </TASK>
> ```
>
> It seems that the `WARN_ON_ONCE(!ep->enabled && ep->address)` in
> usb_ep_queue (https://elixir.bootlin.com/linux/v6.7/source/drivers/usb/gadget/udc/core.c#L290),
> which is invoked by `printer_write`
> (https://elixir.bootlin.com/linux/v6.7/source/drivers/usb/gadget/function/f_printer.c#L669).
>
> If you have any questions or require more information, please feel
> free to contact us.
Do you have a proposed patch that fixes this issue? That's the simplest
way to get this resolved and to get credit for making the fix.
thanks,
greg k-h
On 02.02.24 19:59, Chenyuan Yang wrote:
> Dear Linux Developers for F_printer,
>
> We encountered "WARNING in usb_ep_queue" when testing the f_printer driver with
> Syzkaller and our generated specifications.
>
Hi,
it is clear what happens, but at least to me it is not clear why we allow
a write() before we enable the endpoint. Anyway, does this fix the issue?
Regards
Oliver