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

iwlwifi: mvm: retry init flow if failed

2021-12-08T08:01:14+00:00

commit 5283dd677e52af9db6fe6ad11b2f12220d519d0c upstream.

In some very rare cases the init flow may fail.  In many cases, this is
recoverable, so we can retry.  Implement a loop to retry two more times
after the first attempt failed.

This can happen in two different situations, namely during probe and
during mac80211 start.  For the first case, a simple loop is enough.
For the second case, we need to add a flag to prevent mac80211 from
trying to restart it as well, leaving full control with the driver.

Cc: 
Signed-off-by: Mordechay Goodstein 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid
Signed-off-by: Greg Kroah-Hartman

rt2x00: do not mark device gone on EPROTO errors during start

2021-12-08T08:01:10+00:00

commit ed53ae75693096f1c10b4561edd31a07b631bd72 upstream.

As reported by Exuvo is possible that we have lot's of EPROTO errors
during device start i.e. firmware load. But after that device works
correctly. Hence marking device gone by few EPROTO errors done by
commit e383c70474db ("rt2x00: check number of EPROTO errors") caused
regression - Exuvo device stop working after kernel update. To fix
disable the check during device start.

Link: https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/
Reported-and-tested-by: Exuvo 
Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211111141003.GA134627@wp.pl
Signed-off-by: Greg Kroah-Hartman

ath10k: fix invalid dma_addr_t token assignment

2021-11-17T08:48:50+00:00

commit 937e79c67740d1d84736730d679f3cb2552f990e upstream.

Using a kernel pointer in place of a dma_addr_t token can
lead to undefined behavior if that makes it into cache
management functions. The compiler caught one such attempt
in a cast:

drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface':
drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
 5586 |                         arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf;
      |                                               ^

Looking through how this gets used down the way, I'm fairly
sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL
devices, and if it was accessed, that would be a bug.

Change the assignment to use a known-invalid address token
instead, which avoids the warning and makes it easier to catch
bugs if it does end up getting used.

Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman

wcn36xx: add proper DMA memory barriers in rx path

2021-11-17T08:48:40+00:00

[ Upstream commit 9bfe38e064af5decba2ffce66a2958ab8b10eaa4 ]

This is essentially exactly following the dma_wmb()/dma_rmb() usage
instructions in Documentation/memory-barriers.txt.

The theoretical races here are:

1. DXE (the DMA Transfer Engine in the Wi-Fi subsystem) seeing the
dxe->ctrl & WCN36xx_DXE_CTRL_VLD write before the dxe->dst_addr_l
write, thus performing DMA into the wrong address.

2. CPU reading dxe->dst_addr_l before DXE unsets dxe->ctrl &
WCN36xx_DXE_CTRL_VLD. This should generally be harmless since DXE
doesn't write dxe->dst_addr_l (no risk of freeing the wrong skb).

Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
Signed-off-by: Benjamin Li 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211023001528.3077822-1-benl@squareup.com
Signed-off-by: Sasha Levin

libertas: Fix possible memory leak in probe and disconnect

2021-11-17T08:48:40+00:00

[ Upstream commit 9692151e2fe7a326bafe99836fd1f20a2cc3a049 ]

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff88812c7d7400 (size 512):
  comm "kworker/6:1", pid 176, jiffies 4295003332 (age 822.830s)
  hex dump (first 32 bytes):
    00 68 1e 04 81 88 ff ff 01 00 00 00 00 00 00 00  .h..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] slab_post_alloc_hook+0x9c/0x490
    [] kmem_cache_alloc_trace+0x1f7/0x470
    [] if_usb_probe+0x63/0x446 [usb8xxx]
    [] usb_probe_interface+0x1aa/0x3c0 [usbcore]
    [] really_probe+0x190/0x480
    [] __driver_probe_device+0xf9/0x180
    [] driver_probe_device+0x53/0x130
    [] __device_attach_driver+0x105/0x130
    [] bus_for_each_drv+0x129/0x190
    [] __device_attach+0x1c9/0x270
    [] device_initial_probe+0x20/0x30
    [] bus_probe_device+0x142/0x160
    [] device_add+0x829/0x1300
    [] usb_set_configuration+0xb01/0xcc0 [usbcore]
    [] usb_generic_driver_probe+0x6e/0x90 [usbcore]
    [] usb_probe_device+0x6f/0x130 [usbcore]

cardp is missing being freed in the error handling path of the probe
and the path of the disconnect, which will cause memory leak.

This patch adds the missing kfree().

Fixes: 876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211020120345.2016045-3-wanghai38@huawei.com
Signed-off-by: Sasha Levin

libertas_tf: Fix possible memory leak in probe and disconnect

2021-11-17T08:48:39+00:00

[ Upstream commit d549107305b4634c81223a853701c06bcf657bc3 ]

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff88810a2ddc00 (size 512):
  comm "kworker/6:1", pid 176, jiffies 4295009893 (age 757.220s)
  hex dump (first 32 bytes):
    00 50 05 18 81 88 ff ff 00 00 00 00 00 00 00 00  .P..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] slab_post_alloc_hook+0x9c/0x490
    [] kmem_cache_alloc_trace+0x1f7/0x470
    [] if_usb_probe+0x60/0x37c [libertas_tf_usb]
    [] usb_probe_interface+0x1aa/0x3c0 [usbcore]
    [] really_probe+0x190/0x480
    [] __driver_probe_device+0xf9/0x180
    [] driver_probe_device+0x53/0x130
    [] __device_attach_driver+0x105/0x130
    [] bus_for_each_drv+0x129/0x190
    [] __device_attach+0x1c9/0x270
    [] device_initial_probe+0x20/0x30
    [] bus_probe_device+0x142/0x160
    [] device_add+0x829/0x1300
    [] usb_set_configuration+0xb01/0xcc0 [usbcore]
    [] usb_generic_driver_probe+0x6e/0x90 [usbcore]
    [] usb_probe_device+0x6f/0x130 [usbcore]

cardp is missing being freed in the error handling path of the probe
and the path of the disconnect, which will cause memory leak.

This patch adds the missing kfree().

Fixes: c305a19a0d0a ("libertas_tf: usb specific functions")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211020120345.2016045-2-wanghai38@huawei.com
Signed-off-by: Sasha Levin

mwifiex: Send DELBA requests according to spec

2021-11-17T08:48:38+00:00

[ Upstream commit cc8a8bc37466f79b24d972555237f3d591150602 ]

While looking at on-air packets using Wireshark, I noticed we're never
setting the initiator bit when sending DELBA requests to the AP: While
we set the bit on our del_ba_param_set bitmask, we forget to actually
copy that bitmask over to the command struct, which means we never
actually set the initiator bit.

Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command
struct.

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Jonas Dreßler 
Acked-by: Pali Rohár 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl
Signed-off-by: Sasha Levin

rsi: stop thread firstly in rsi_91x_init() error handling

2021-11-17T08:48:38+00:00

[ Upstream commit 515e7184bdf0a3ebf1757cc77fb046b4fe282189 ]

When fail to init coex module, free 'common' and 'adapter' directly, but
common->tx_thread which will access 'common' and 'adapter' is running at
the same time. That will trigger the UAF bug.

==================================================================
BUG: KASAN: use-after-free in rsi_tx_scheduler_thread+0x50f/0x520 [rsi_91x]
Read of size 8 at addr ffff8880076dc000 by task Tx-Thread/124777
CPU: 0 PID: 124777 Comm: Tx-Thread Not tainted 5.15.0-rc5+ #19
Call Trace:
 dump_stack_lvl+0xe2/0x152
 print_address_description.constprop.0+0x21/0x140
 ? rsi_tx_scheduler_thread+0x50f/0x520
 kasan_report.cold+0x7f/0x11b
 ? rsi_tx_scheduler_thread+0x50f/0x520
 rsi_tx_scheduler_thread+0x50f/0x520
...

Freed by task 111873:
 kasan_save_stack+0x1b/0x40
 kasan_set_track+0x1c/0x30
 kasan_set_free_info+0x20/0x30
 __kasan_slab_free+0x109/0x140
 kfree+0x117/0x4c0
 rsi_91x_init+0x741/0x8a0 [rsi_91x]
 rsi_probe+0x9f/0x1750 [rsi_usb]

Stop thread before free 'common' and 'adapter' to fix it.

Fixes: 2108df3c4b18 ("rsi: add coex support")
Signed-off-by: Ziyang Xuan 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211015040335.1021546-1-william.xuanziyang@huawei.com
Signed-off-by: Sasha Levin

mt76: mt76x02: fix endianness warnings in mt76x02_mac.c

2021-11-17T08:48:38+00:00

[ Upstream commit c33edef520213feccebc22c9474c685b9fb60611 ]

Fix the following sparse warning in mt76x02_mac_write_txwi and
mt76x02_mac_tx_rate_val routines:
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:237:19:
	warning: restricted __le16 degrades to intege
	warning: cast from restricted __le16
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:383:28:
	warning: incorrect type in assignment (different base types)
	expected restricted __le16 [usertype] rate
	got unsigned long

Fixes: db9f11d3433f7 ("mt76: store wcid tx rate info in one u32 reduce locking")
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Felix Fietkau 
Signed-off-by: Sasha Levin

ath10k: fix max antenna gain unit

2021-11-17T08:48:37+00:00

[ Upstream commit 0a491167fe0cf9f26062462de2a8688b96125d48 ]

Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
steps). This isn't the case for max_antenna_gain - which is still expected
by the firmware as dB.

The firmware is converting it from dB to the internal (twicepower)
representation when it calculates the limits of a channel. This can be seen
in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
expected 12 (6 dB), the tpc_stats shows 24 (12 dB).

Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.

Fixes: 02256930d9b8 ("ath10k: use proper tx power unit")
Signed-off-by: Sven Eckelmann 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20190611172131.6064-1-sven@narfation.org
Signed-off-by: Sasha Levin