linux-stable.git/drivers/net/wireless, branch v5.10.7

rtlwifi: rise completion at the last step of firmware callback

2021-01-12T19:18:26+00:00

commit 4dfde294b9792dcf8615b55c58f093d544f472f0 upstream.

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: Ping-Ke Shih 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20201214053106.7748-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman

mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start

2021-01-09T12:46:25+00:00

[ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d ]

mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking
the destination size may trigger a buffer overflower,
which a local user could use to cause denial of service
or the execution of arbitrary code.
Fix it by putting the length check before calling memcpy().

Signed-off-by: Zhang Xiaohui 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20201206084801.26479-1-ruc_zhangxiaohui@163.com
Signed-off-by: Sasha Levin

mt76: add back the SUPPORTS_REORDERING_BUFFER flag

2020-12-30T10:54:28+00:00

commit ed89b89330b521f20682ead6bf93e1014b21a200 upstream.

It was accidentally dropped while adding multiple wiphy support
Fixes fast-rx support and avoids handling reordering in both mac80211
and the driver

Cc: stable@vger.kernel.org
Fixes: c89d36254155 ("mt76: add function for allocating an extra wiphy")
Signed-off-by: Felix Fietkau 
Signed-off-by: Greg Kroah-Hartman

ath11k: Fix incorrect tlvs in scan start command

2020-12-30T10:53:51+00:00

[ Upstream commit f57ad6a9885e8399897daee3249cabccf9c972f8 ]

Currently 6G specific tlvs have duplicate entries which is causing
scan failures. Fix this by removing the duplicate entries of the same
tlv. This also fixes out-of-bound memory writes caused due to
adding tlvs when num_hint_bssid and num_hint_s_ssid are ZEROs.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01386-QCAHKSWPL_SILICONZ-1

Fixes: 74601ecfef6e ("ath11k: Add support for 6g scan hint")
Reported-by: Carl Huang 
Signed-off-by: Pradeep Kumar Chitrapu 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/1607609124-17250-7-git-send-email-kvalo@codeaurora.org
Signed-off-by: Sasha Levin

iwlwifi: mvm: hook up missing RX handlers

2020-12-30T10:53:46+00:00

[ Upstream commit 8a59d39033c35bb484f6bd91891db86ebe07fdc2 ]

The RX handlers for probe response data and channel switch weren't
hooked up properly, fix that.

Fixes: 86e177d80ff7 ("iwlwifi: mvm: add NOA and CSA to a probe response")
Fixes: d3a108a48dc6 ("iwlwifi: mvm: Support CSA countdown offloading")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.2d07dcee0d35.I07a61b5d734478db57d9434ff303e4c90bf6c32b@changeid
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: dbg-tlv: fix old length in is_trig_data_contained()

2020-12-30T10:53:46+00:00

[ Upstream commit 58a1c9f9a9b6b9092ae10b84f6b571a06596e296 ]

There's a bug in the lengths - the 'old length' needs to be calculated
using the 'old' pointer, of course, likely a copy/paste mistake. Fix
this.

Reported-by: Daniel Gabay 
Signed-off-by: Johannes Berg 
Fixes: cf29c5b66b9f ("iwlwifi: dbg_ini: implement time point handling")
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.c0105ddffa74.I1ddb243053ff763c91b663748b6a593ecc3b5634@changeid
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

adm8211: fix error return code in adm8211_probe()

2020-12-30T10:53:40+00:00

[ Upstream commit 05c2a61d69ea306e891884a86486e1ef37c4b78d ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
Reported-by: Hulk Robot 
Signed-off-by: Zhang Changzhong 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/1607071638-33619-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Sasha Levin

mt76: fix tkip configuration for mt7615/7663 devices

2020-12-30T10:53:35+00:00

[ Upstream commit 930e0eaddf810cfa90e114a0df02f48539e1346f ]

Fix Tx-Rx MIC overwrite during TKIP hw key configuration

Fixes: 01cfc1b45421 ("mt76: mt7615: add BIP_CMAC_128 cipher support")
Tested-by: YN Chen 
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Felix Fietkau 
Signed-off-by: Sasha Levin

mt76: fix memory leak if device probing fails

2020-12-30T10:53:35+00:00

[ Upstream commit bc348defcc6eceeb4f7784bf9a263ddb72fd3fb4 ]

Run mt76_free_device instead of ieee80211_free_hw if device probing
fails in order to remove the already allocated mt76 workqueue

Fixes: a86f1d01f5ce5 ("mt76: move mt76 workqueue in common code")
Fixes: f1d962369d568 ("mt76: mt7915: implement HE per-rate tx power support")
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Felix Fietkau 
Signed-off-by: Sasha Levin

mt76: dma: fix possible deadlock running mt76_dma_cleanup

2020-12-30T10:53:35+00:00

[ Upstream commit 5f0ce5848733b86deaba1c6d102e20479230b20a ]

Fix the following possible deadlock reported by lockdep disabling BH
running mt76_free_pending_txwi()

================================
WARNING: inconsistent lock state
5.9.0-rc6 #14 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
rmmod/1227 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff888156a83530 (&dev->lock#2){+.?.}-{2:2}, at: mt76_dma_cleanup+0x125/0x150 [mt76]
{IN-SOFTIRQ-W} state was registered at:
  __lock_acquire+0x20c/0x6b0
  lock_acquire+0x9d/0x220
  _raw_spin_lock+0x2c/0x70
  mt76_dma_tx_cleanup+0xc7/0x200 [mt76]
  mt76x02_poll_tx+0x31/0xb0 [mt76x02_lib]
  napi_poll+0x3a/0x100
  net_rx_action+0xa8/0x200
  __do_softirq+0xc4/0x430
  asm_call_on_stack+0xf/0x20
  do_softirq_own_stack+0x49/0x60
  irq_exit_rcu+0x9a/0xd0
  common_interrupt+0xa4/0x190
  asm_common_interrupt+0x1e/0x40
irq event stamp: 9915
hardirqs last  enabled at (9915): [] __free_pages_ok+0x336/0x3b0
hardirqs last disabled at (9914): [] __free_pages_ok+0x2fe/0x3b0
softirqs last  enabled at (9912): [] mt76_dma_rx_cleanup+0xa2/0x120 [mt76]
softirqs last disabled at (9846): [] mt76_dma_rx_cleanup+0x1a/0x120 [mt76]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&dev->lock#2);
  
    lock(&dev->lock#2);

 *** DEADLOCK ***

1 lock held by rmmod/1227:
 #0: ffff88815b5eb240 (&dev->mutex){....}-{3:3}, at: driver_detach+0xb5/0x110

stack backtrace:
CPU: 1 PID: 1227 Comm: rmmod Kdump: loaded Not tainted 5.9.0-rc6-wdn-src+ #14
Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009
Call Trace:
 dump_stack+0x77/0xa0
 mark_lock_irq.cold+0x15/0x39
 mark_lock+0x1fc/0x500
 mark_usage+0xc7/0x140
 __lock_acquire+0x20c/0x6b0
 ? find_held_lock+0x2b/0x80
 ? sched_clock_cpu+0xc/0xb0
 lock_acquire+0x9d/0x220
 ? mt76_dma_cleanup+0x125/0x150 [mt76]
 _raw_spin_lock+0x2c/0x70
 ? mt76_dma_cleanup+0x125/0x150 [mt76]
 mt76_dma_cleanup+0x125/0x150 [mt76]
 mt76x2_cleanup+0x5a/0x70 [mt76x2e]
 mt76x2e_remove+0x18/0x30 [mt76x2e]
 pci_device_remove+0x36/0xa0
 __device_release_driver+0x16c/0x220
 driver_detach+0xcf/0x110
 bus_remove_driver+0x56/0xca
 pci_unregister_driver+0x36/0x80
 __do_sys_delete_module.constprop.0+0x127/0x200
 ? syscall_enter_from_user_mode+0x1d/0x50
 ? trace_hardirqs_on+0x1c/0xe0
 do_syscall_64+0x33/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7ff0da54e36b
Code: 73 01 c3 48 8b 0d 2d 0b 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 0a 0c 00 f7 d8 64 89 01 48

Fixes: dd57a95cfddc ("mt76: move txwi handling code to dma.c, since it is mmio specific")
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Felix Fietkau 
Signed-off-by: Sasha Levin