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
