linux-stable.git/drivers/net/wireless, branch linux-5.14.y

ath10k: fix invalid dma_addr_t token assignment

2021-11-17T10:04:51+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: Channel list update before hardware scan

2021-11-17T10:04:17+00:00

[ Upstream commit d707f812bb0513ea0030d0c9fe2a456bae5a4583 ]

The channel scan list must be updated before triggering a hardware scan
so that firmware takes into account the regulatory info for each single
channel such as active/passive config, power, DFS, etc... Without this
the firmware uses its own internal default channel configuration, which
is not aligned with mac80211 regulatory rules, and misses several
channels (e.g. 144).

Fixes: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support")
Signed-off-by: Loic Poulain 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/1635175328-25642-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin

wcn36xx: Fix discarded frames due to wrong sequence number

2021-11-17T10:04:17+00:00

[ Upstream commit 113f304dbc1627c6ec9d5329d839964095768980 ]

The firmware is offering features such as ARP offload, for which
firmware crafts its own (QoS)packets without waking up the host.
Point is that the sequence numbers generated by the firmware are
not in sync with the host mac80211 layer and can cause packets
such as firmware ARP reponses to be dropped by the AP (too old SN).

To fix this we need to let the firmware manages the sequence
numbers by its own (except for QoS null frames). There is a SN
counter for each QoS queue and one global/baseline counter for
Non-QoS.

Fixes: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211")
Signed-off-by: Loic Poulain 
Tested-by: Bryan O'Donoghue 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin

wcn36xx: add proper DMA memory barriers in rx path

2021-11-17T10:04:16+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-17T10:04:16+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-17T10:04:16+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

ath10k: fix module load regression with iram-recovery feature

2021-11-17T10:04:15+00:00

[ Upstream commit 6f8c8bf4c7c9be1c42088689fd4370e06b46608a ]

Commit 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But
this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit
was not enabled in the ath10k coredump_mask module parameter:

[ 2209.328190] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 2209.434414] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
[ 2209.547191] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 cbade90a
[ 2210.896485] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id 0:1 crc32 a040efc2
[ 2213.603339] ath10k_pci 0000:02:00.0: failed to copy target iram contents: -12
[ 2213.839027] ath10k_pci 0000:02:00.0: could not init core (-12)
[ 2213.933910] ath10k_pci 0000:02:00.0: could not probe fw (-12)

And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA
enabled so anyone using a firmware with iram-recovery feature would fail. To my
knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099
enabled the feature.

The reason for regression was that ath10k_core_copy_target_iram() used
ath10k_coredump_get_mem_layout() to get the memory layout, but when
ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out
with an error.

While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is
disabled but the firmware has iram-recovery enabled the module load fails with
similar error messages. I fixed that by returning 0 from
ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns
NULL.

Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139

Fixes: 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
Signed-off-by: Abinaya Kalaiselvan 
Signed-off-by: Jouni Malinen 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211020075054.23061-1-kvalo@codeaurora.org
Signed-off-by: Sasha Levin

mt76: mt7615: mt7622: fix ibss and meshpoint

2021-11-17T10:04:14+00:00

[ Upstream commit 753453afacc0243bd45de45e34218a8d17493e8f ]

commit 7f4b7920318b ("mt76: mt7615: add ibss support") introduced IBSS
and commit f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh")
meshpoint support.

Both used in the "get_omac_idx"-function:

	if (~mask & BIT(HW_BSSID_0))
		return HW_BSSID_0;

With commit d8d59f66d136 ("mt76: mt7615: support 16 interfaces") the
ibss and meshpoint mode should "prefer hw bssid slot 1-3". However,
with that change the ibss or meshpoint mode will not send any beacon on
the mt7622 wifi anymore. Devices were still able to exchange data but
only if a bssid already existed. Two mt7622 devices will never be able
to communicate.

This commits reverts the preferation of slot 1-3 for ibss and
meshpoint. Only NL80211_IFTYPE_STATION will still prefer slot 1-3.

Tested on Banana Pi R64.

Fixes: d8d59f66d136 ("mt76: mt7615: support 16 interfaces")
Signed-off-by: Nick Hainke 
Acked-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20211007225725.2615-1-vincent@systemli.org
Signed-off-by: Sasha Levin

iwlwifi: pnvm: read EFI data only if long enough

2021-11-17T10:04:12+00:00

[ Upstream commit e864a77f51d0d8113b49cf7d030bc9dc911c8176 ]

If the data we get from EFI is not even long enough for
the package struct we expect then ignore it entirely.

Signed-off-by: Johannes Berg 
Fixes: a1a6a4cf49ec ("iwlwifi: pnvm: implement reading PNVM from UEFI")
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.33feba783518.I54a5cf33975d0330792b3d208b225d479e168f32@changeid
Signed-off-by: Sasha Levin

iwlwifi: pnvm: don't kmemdup() more than we have

2021-11-17T10:04:12+00:00

[ Upstream commit 0f892441d8c353144e3669b7991fa5fe0bd353e9 ]

We shouldn't kmemdup() more data than we have, that might
cause the code to crash. Fix that by updating the length
before the kmemdup.

Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ab0e64c3fba9.Ic6a3295fc384750b51b4270bf0b7d94984a139f2@changeid
Signed-off-by: Sasha Levin