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
