Re: [PATCH] Revert "ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb"

Viktor Jägersküpper [off-list ref] writes:

Kalle Valo wrote:

quoted

Viktor Jägersküpper [off-list ref] writes:

quoted

Kalle Valo writes:

quoted

Roman Mamedov [off-list ref] writes:

quoted

On Sat,  4 Apr 2020 12:18:38 +0800
Qiujun Huang [off-list ref] wrote:

quoted

In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
usb_ifnum_to_if(urb->dev, 0)
But it isn't always true.

The case reported by syzbot:
https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com (local)
usb 2-1: new high-speed USB device number 2 using dummy_hcd
usb 2-1: config 1 has an invalid interface number: 2 but max is 0
usb 2-1: config 1 has no interface number 0
usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
1.08
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
general protection fault, probably for non-canonical address
0xdffffc0000000015: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0

Call Trace
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
__do_softirq+0x21e/0x950 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x178/0x1a0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:546 [inline]
smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829

Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <redacted>

This causes complete breakage of ath9k operation across all the stable kernel
series it got backported to, and I guess the mainline as well. Please see:
https://bugzilla.kernel.org/show_bug.cgi?id=208251
https://bugzilla.redhat.com/show_bug.cgi?id=1848631

So there's no fix for this? I was under impression that someone fixed
this, but maybe I'm mixing with something else.

If this is not fixed can someone please submit a patch to revert the
offending commit (or commits) so that we get ath9k working again?

This reverts commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05
("ath9k: Fix general protection fault
in ath9k_hif_usb_rx_cb") because the driver gets stuck like this:

  [    5.778803] usb 1-5: Manufacturer: ATHEROS
  [   21.697488] usb 1-5: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
  [   21.701377] usbcore: registered new interface driver ath9k_htc
  [ 22.053705] usb 1-5: ath9k_htc: Transferred FW:
ath9k_htc/htc_9271-1.4.0.fw, size: 51008
  [   22.306182] ath9k_htc 1-5:1.0: ath9k_htc: HTC initialized with 33 credits
  [  115.708513] ath9k_htc: Failed to initialize the device
  [  115.708683] usb 1-5: ath9k_htc: USB layer deinitialized

Reported-by: Roman Mamedov <redacted>
Ref: https://bugzilla.kernel.org/show_bug.cgi?id=208251
Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb")
Tested-by: Viktor Jägersküpper <redacted>
Signed-off-by: Viktor Jägersküpper <redacted>
---

I couldn't find any fix for this, so here is the patch which reverts the
offending commit. I have tested it with 5.8.0-rc3 and with 5.7.4.

Feel free to change the commit message if it is necessary or appropriate, I am
just a user affected by this bug.

This was badly formatted:

https://patchwork.kernel.org/patch/11636783/

But v2 looks correct:

https://patchwork.kernel.org/patch/11637341/

Thanks, I'll take a closer look at this as soon as I can.

Hi Kalle,

it seems you didn't have time for this so far. If you don't have time at the
moment, is there someone else who can fix this? Reverting the commit is just the
first and easy option and fixing this properly can be done after that.

I was on vacation, I will get to your patch in the next few days.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches