1. 21 Dec, 2020 1 commit
  2. 20 Dec, 2020 5 commits
  3. 18 Dec, 2020 2 commits
  4. 17 Dec, 2020 7 commits
    • Ping-Ke Shih's avatar
      rtlwifi: rise completion at the last step of firmware callback · 4dfde294
      Ping-Ke Shih authored
      request_firmware_nowait() which schedules another work is used to load
      firmware when USB is probing. If USB is unplugged before running the
      firmware work, it goes disconnect ops, and then causes use-after-free.
      Though we wait for completion of firmware work before freeing the hw,
      firmware callback rises completion too early. So I move it to the
      last step.
      
      usb 5-1: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2
      rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
      rtlwifi: Selected firmware is not available
      ==================================================================
      BUG: KASAN: use-after-free in rtl_fw_do_work.cold+0x68/0x6a drivers/net/wireless/realtek/rtlwifi/core.c:93
      Write of size 4 at addr ffff8881454cff50 by task kworker/0:6/7379
      
      CPU: 0 PID: 7379 Comm: kworker/0:6 Not tainted 5.10.0-rc7-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events request_firmware_work_func
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x107/0x163 lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xae/0x4c8 mm/kasan/report.c:385
       __kasan_report mm/kasan/report.c:545 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
       rtl_fw_do_work.cold+0x68/0x6a drivers/net/wireless/realtek/rtlwifi/core.c:93
       request_firmware_work_func+0x12c/0x230 drivers/base/firmware_loader/main.c:1079
       process_one_work+0x933/0x1520 kernel/workqueue.c:2272
       worker_thread+0x64c/0x1120 kernel/workqueue.c:2418
       kthread+0x38c/0x460 kernel/kthread.c:292
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
      
      The buggy address belongs to the page:
      page:00000000f54435b3 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1454cf
      flags: 0x200000000000000()
      raw: 0200000000000000 0000000000000000 ffffea00051533c8 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881454cfe00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff8881454cfe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      >ffff8881454cff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                       ^
       ffff8881454cff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff8881454d0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      
      Reported-by: syzbot+65be4277f3c489293939@syzkaller.appspotmail.com
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201214053106.7748-1-pkshih@realtek.com
      4dfde294
    • Lorenzo Bianconi's avatar
      mt76: mt76u: fix NULL pointer dereference in mt76u_status_worker · e7f6f893
      Lorenzo Bianconi authored
      Fix the following NULL pointer dereference in mt76u_status_worker that
      can occur if status thread runs before allocating tx queues
      
      [   31.395373] BUG: kernel NULL pointer dereference, address: 000000000000002c
      [   31.395769] #PF: supervisor read access in kernel mode
      [   31.395985] #PF: error_code(0x0000) - not-present page
      [   31.396178] PGD 0 P4D 0
      [   31.396277] Oops: 0000 [#1] SMP
      [   31.396430] CPU: 3 PID: 337 Comm: mt76-usb-status Not tainted 5.10.0-rc1-kvm+ #49
      [   31.396703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-3.fc33 04/01/2014
      [   31.397048] RIP: 0010:mt76u_status_worker+0x2b/0x190
      [   31.397931] RSP: 0018:ffffc9000076fe98 EFLAGS: 00010282
      [   31.398118] RAX: 0000000000000001 RBX: ffff888111203fe8 RCX: 0000000000000000
      [   31.398400] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff888111203fe8
      [   31.398668] RBP: ffff888111201d00 R08: 000000000000038c R09: 000000000000009b
      [   31.398952] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      [   31.399235] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810c987300
      [   31.399494] FS:  0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000
      [   31.399767] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   31.399991] CR2: 000000000000002c CR3: 0000000103525000 CR4: 00000000000006a0
      [   31.400236] Call Trace:
      [   31.400348]  ? schedule+0x3e/0xa0
      [   31.400514]  __mt76_worker_fn+0x71/0xa0
      [   31.400634]  ? mt76_get_min_avg_rssi+0x110/0x110
      [   31.400827]  kthread+0x118/0x130
      [   31.400984]  ? __kthread_bind_mask+0x60/0x60
      [   31.401212]  ret_from_fork+0x1f/0x30
      [   31.401353] Modules linked in:
      [   31.401480] CR2: 000000000000002c
      [   31.401627] ---[ end trace 8bf174505cc34851 ]---
      [   31.401798] RIP: 0010:mt76u_status_worker+0x2b/0x190
      [   31.402636] RSP: 0018:ffffc9000076fe98 EFLAGS: 00010282
      [   31.402829] RAX: 0000000000000001 RBX: ffff888111203fe8 RCX: 0000000000000000
      [   31.403118] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff888111203fe8
      [   31.403424] RBP: ffff888111201d00 R08: 000000000000038c R09: 000000000000009b
      [   31.403689] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      [   31.403933] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810c987300
      [   31.404209] FS:  0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000
      [   31.404482] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   31.404726] CR2: 000000000000002c CR3: 0000000103525000 CR4: 00000000000006a0
      [   31.405294] mt76x0u: probe of 1-1:1.0 failed with error -110
      [   31.406007] usb 1-1: USB disconnect, device number 2
      [   31.840756] usb 1-1: new high-speed USB device number 3 using xhci_hcd
      [   32.461295] usb 1-1: reset high-speed USB device number 3 using xhci_hcd
      [   32.659932] mt76x0u 1-1:1.0: ASIC revision: 76100002 MAC revision: 76502000
      [   33.197032] mt76x0u 1-1:1.0: EEPROM ver:02 fae:01
      
      Fixes: 9daf27e6 ("mt76: mt76u: use dedicated thread for status work")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/cd44dc407cf3e5f27688105d4a75fb1c68e62b06.1607419147.git.lorenzo@kernel.org
      e7f6f893
    • Dan Carpenter's avatar
      ath11k: Fix ath11k_pci_fix_l1ss() · 30d08503
      Dan Carpenter authored
      All these conditions are reversed so presumably most of the function is
      dead code. This caused a spurious warning:
      
      [   95.734922] ath11k_pci 0000:06:00.0: failed to set sysclk: 0
      
      Fixes: 06999407 ("ath11k: pci: fix L1ss clock unstable problem")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/X9nGDHiTh+Z+asDy@mwanda
      30d08503
    • Dan Carpenter's avatar
      ath11k: Fix error code in ath11k_core_suspend() · 9b094562
      Dan Carpenter authored
      The "if (!ret)" condition is inverted and it should be "if (ret)".  It means
      that we return success when we had intended to return an error code. This also
      caused a spurious warning even when the suspend was successful:
      
      [  297.186612] ath11k_pci 0000:06:00.0: failed to suspend hif: 0
      
      Fixes: d1b0c338 ("ath11k: implement suspend for QCA6390 PCI devices")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/X9nF17L2/EKOSbn/@mwanda
      9b094562
    • Carl Huang's avatar
      ath11k: start vdev if a bss peer is already created · aa44b2f3
      Carl Huang authored
      For QCA6390, bss peer must be created before vdev is to start. This
      change is to start vdev if a bss peer is created. Otherwise, ath11k
      delays to start vdev.
      
      This fixes an issue in a case where HT/VHT/HE settings change between
      authentication and association, e.g., due to the user space request
      to disable HT.
      
      Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
      Signed-off-by: default avatarCarl Huang <cjhuang@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201211051358.9191-1-cjhuang@codeaurora.org
      aa44b2f3
    • Carl Huang's avatar
      ath11k: fix crash caused by NULL rx_channel · 35970106
      Carl Huang authored
      During connect and disconnect stress test, crashed happened
      because ar->rx_channel is NULL. Fix it by checking whether
      ar->rx_channel is NULL.
      
      Crash stack is as below:
      RIP: 0010:ath11k_dp_rx_h_ppdu+0x110/0x230 [ath11k]
      [ 5028.808963]  ath11k_dp_rx_wbm_err+0x14a/0x360 [ath11k]
      [ 5028.808970]  ath11k_dp_rx_process_wbm_err+0x41c/0x520 [ath11k]
      [ 5028.808978]  ath11k_dp_service_srng+0x25e/0x2d0 [ath11k]
      [ 5028.808982]  ath11k_pci_ext_grp_napi_poll+0x23/0x80 [ath11k_pci]
      [ 5028.808986]  net_rx_action+0x27e/0x400
      [ 5028.808990]  __do_softirq+0xfd/0x2bb
      [ 5028.808993]  irq_exit+0xa6/0xb0
      [ 5028.808995]  do_IRQ+0x56/0xe0
      [ 5028.808997]  common_interrupt+0xf/0xf
      
      Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
      Signed-off-by: default avatarCarl Huang <cjhuang@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201211055613.9310-1-cjhuang@codeaurora.org
      35970106
    • Colin Ian King's avatar
      ath11k: add missing null check on allocated skb · 292bff94
      Colin Ian King authored
      Currently the null check on a newly allocated skb is missing and
      this can lead to a null pointer dereference is the allocation fails.
      Fix this by adding a null check and returning -ENOMEM.
      
      Addresses-Coverity: ("Dereference null return")
      Fixes: 43ed15e1 ("ath11k: put hw to DBS using WMI_PDEV_SET_HW_MODE_CMDID")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201214232417.84556-1-colin.king@canonical.com
      292bff94
  5. 13 Dec, 2020 1 commit
  6. 12 Dec, 2020 24 commits