Re: WARNING in hif_usb_alloc_rx_urbs/usb_submit_urb

[Alan Stern]

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