Re: WARNING in hif_usb_alloc_rx_urbs/usb_submit_urb

[Fedor Pchelkin]

On 19.08.2022 21:46, Alan Stern wrote:
> On Fri, Aug 19, 2022 at 09:34:44PM +0300, Fedor Pchelkin wrote:
> > Hi Alan,
> >
> > Fri, 9 Oct 2020 at 21:55:51 UTC+3, Alan Stern wrote:
> > > To the ath9k_htc maintainers:
> > > This is an attempt to fix a bug detected by the syzbot fuzzer. The bug
> > > arises when a USB device claims to be an ATH9K but doesn't have the
> > > expected endpoints. (In this case there was a bulk endpoint where the
> > > driver expected an interrupt endpoint.) The kernel needs to be able to
> > > handle such devices without getting an internal error.
> >
> > We are facing the similar warnings [1] in
> > hif_usb_alloc_rx_urbs/usb_submit_urb:
> >
> > usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> > usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> > ------------[ cut here ]------------
> > usb 1-1: BOGUS urb xfer, pipe 3 != type 1
> > WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493
> > usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493
> > Modules linked in:
> > CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1
> > 04/01/2014
> > Workqueue: events request_firmware_work_func
> > RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493
> > Code: 84 d4 02 00 00 e8 0e 00 80 fc 4c 89 ef e8 06 2d 35 ff 41 89 d8 44 89
> > e1 4c 89 f2 48 89 c6 48 c7 c7 c0 f0 a8 88 e8 0e a6 b9 02 <0f> 0b e9 c6 f8 ff
> > ff e8 e2 ff 7f fc 48 81 c5 88 06 00 00 e9 f2 f7
> > RSP: 0018:ffff888147227b60 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
> > RDX: ffff888147218000 RSI: ffffffff815909c5 RDI: ffffed1028e44f5e
> > RBP: ffff888021509850 R08: 0000000000000001 R09: ffff888237d38ba7
> > R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003
> > R13: ffff888021a330a0 R14: ffff88800f82b5a0 R15: ffff88801466a900
> > FS:  0000000000000000(0000) GS:ffff888237d00000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 000055b2994526c8 CR3: 000000001e730000 CR4: 0000000000350ee0
> > Call Trace:
> >   ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908
> > [inline]
> >   ath9k_hif_usb_alloc_urbs+0x75e/0x1010
> > drivers/net/wireless/ath/ath9k/hif_usb.c:1019
> >   ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109
> > [inline]
> >   ath9k_hif_usb_firmware_cb+0x142/0x530
> > drivers/net/wireless/ath/ath9k/hif_usb.c:1242
> >   request_firmware_work_func+0x12e/0x240
> > drivers/base/firmware_loader/main.c:1097
> >   process_one_work+0x9af/0x1600 kernel/workqueue.c:2279
> >   worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425
> >   kthread+0x3b4/0x4a0 kernel/kthread.c:313
> >   ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299
> >
> > Fri, 9 Oct 2020 at 21:55:51 UTC+3, Alan Stern wrote:
> > > I don't know if all the devices used by the ath9k_htc driver are
> > > expected to have all of these endpoints and no others. I just added
> > > checks for the ones listed in the hif_usb.h file.
> >
> > I agree with you: kernel should definitely handle itself the situation
> > when endpoint definitions do not correspond to the expected ones because
> > this problem arises in Syzkaller cases. I suppose adding the endpoints
> > to be checked listed in the hif_usb.h file would be enough.
> >
> > However, it is probable that those warnings can only be triggered with
> > fuzzer and can't happen in real applications. Perhaps it is Syzkaller
> > which does not name endpoints correctly in a way that suits real
> > implementation. But overall, some method of checking endpoints should
> > be implemented inside ath9k driver, and the code you proposed does this
> > functionality.
> >
> > [1]: https://groups.google.com/g/syzkaller-bugs/c/umu68ITBsRg/m/xy8dtA5JAQAJ
>
> Good.  Should I add your Acked-by: to the patch and submit it?
>
> Alan Stern

Yeah, okay.

Fedor