kernel.git/drivers/net/wireless/marvell, branch linux-5.17.y

mwifiex: add mutex lock for call in mwifiex_dfs_chan_sw_work_queue

2022-06-09T08:25:18Z

[ Upstream commit 3e12968f6d12a34b540c39cbd696a760cc4616f0 ] cfg80211_ch_switch_notify uses ASSERT_WDEV_LOCK to assert that net_device->ieee80211_ptr->mtx (which is the same as priv->wdev.mtx) is held during the function's execution. mwifiex_dfs_chan_sw_work_queue is one of its callers, which does not hold that lock, therefore violating the assertion. Add a lock around the call. Disclaimer: I am currently working on a static analyser to detect missing locks. This was a reported case. I manually verified the report by looking at the code, so that I do not send wrong information or patches. After concluding that this seems to be a true positive, I created this patch. However, as I do not in fact have this particular hardware, I was unable to test it. Reviewed-by: Brian Norris Signed-off-by: Niels Dossche Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220321225515.32113-1-dossche.niels@gmail.com Signed-off-by: Sasha Levin

libertas_tf: Add missing __packed annotations

2021-12-08T18:39:54Z

The earlier __packed annotations added in commit d71038c05970 ("libertas: Fix alignment issues in libertas core") were not duplicated when libertas_af was added in commit 7670e62c7ed6 ("libertas_tf: header file"), even though they share several structure definitions. Add the missing annotations which commit 642a57475b30 ("libertas_tf: Use struct_group() for memcpy() region") exposed. Quoting the prior libertas fix: "Data structures that come over the wire from the WLAN firmware must be packed." Reported-by: kernel test robot Link: https://lore.kernel.org/linux-mm/202111302102.apaePz2J-lkp@intel.com Fixes: 642a57475b30 ("libertas_tf: Use struct_group() for memcpy() region") Fixes: 7670e62c7ed6 ("libertas_tf: header file") Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211201173234.578124-3-keescook@chromium.org

libertas: Add missing __packed annotation with struct_group()

2021-12-08T18:39:53Z

Build testing of the newly added struct_group() usage missed smaller architecture width tests for changes to pahole output. Add the missed __packed annotation with struct_group() usage in a __packed struct. Reported-by: kernel test robot Link: https://lore.kernel.org/linux-mm/202111302102.apaePz2J-lkp@intel.com Fixes: 5fd32ae0433a ("libertas: Use struct_group() for memcpy() region") Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211201173234.578124-2-keescook@chromium.org

mwifiex: Fix possible ABBA deadlock

2021-12-08T18:38:29Z

Quoting Jia-Ju Bai : mwifiex_dequeue_tx_packet() spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 1432 (Lock A) mwifiex_send_addba() spin_lock_bh(&priv->sta_list_spinlock); --> Line 608 (Lock B) mwifiex_process_sta_tx_pause() spin_lock_bh(&priv->sta_list_spinlock); --> Line 398 (Lock B) mwifiex_update_ralist_tx_pause() spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 941 (Lock A) Similar report for mwifiex_process_uap_tx_pause(). While the locking expectations in this driver are a bit unclear, the Fixed commit only intended to protect the sta_ptr, so we can drop the lock as soon as we're done with it. IIUC, this deadlock cannot actually happen, because command event processing (which calls mwifiex_process_sta_tx_pause()) is sequentialized with TX packet processing (e.g., mwifiex_dequeue_tx_packet()) via the main loop (mwifiex_main_process()). But it's good not to leave this potential issue lurking. Fixes: f0f7c2275fb9 ("mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c") Cc: Douglas Anderson Reported-by: TOTE Robot Link: https://lore.kernel.org/linux-wireless/0e495b14-efbb-e0da-37bd-af6bd677ee2c@gmail.com/ Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YaV0pllJ5p/EuUat@google.com

mwl8k: Use named struct for memcpy() region

2021-11-29T10:46:07Z

In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use named struct in struct mwl8k_cmd_set_key around members key_material, tkip_tx_mic_key, and tkip_rx_mic_key so they can be referenced together. This will allow memcpy() and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of key_material. "pahole" shows no size nor member offset changes to struct mwl8k_cmd_set_key. "objdump -d" shows no object code changes. Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211119004905.2348143-1-keescook@chromium.org

libertas_tf: Use struct_group() for memcpy() region

2021-11-29T10:44:55Z

In preparation for FORTIFY_SOURCE performing compile-time and run-time field array bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use struct_group() in struct txpd around members tx_dest_addr_high and tx_dest_addr_low so they can be referenced together. This will allow memcpy() and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of tx_dest_addr_high. "pahole" shows no size nor member offset changes to struct txpd. "objdump -d" shows no object code changes. Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211118184121.1283821-1-keescook@chromium.org

libertas: Use struct_group() for memcpy() region

2021-11-29T10:44:29Z

In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use struct_group() in struct txpd around members tx_dest_addr_high and tx_dest_addr_low so they can be referenced together. This will allow memcpy() and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of queue_id. "pahole" shows no size nor member offset changes to struct txpd. "objdump -d" shows no object code changes. Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211118184104.1283637-1-keescook@chromium.org

mwifiex: Ignore BTCOEX events from the 88W8897 firmware

2021-11-26T16:30:13Z

The firmware of the 88W8897 PCIe+USB card sends those events very unreliably, sometimes bluetooth together with 2.4ghz-wifi is used and no COEX event comes in, and sometimes bluetooth is disabled but the coexistance mode doesn't get disabled. This means we sometimes end up capping the rx/tx window size while bluetooth is not enabled anymore, artifically limiting wifi speeds even though bluetooth is not being used. Since we can't fix the firmware, let's just ignore those events on the 88W8897 device. From some Wireshark capture sessions it seems that the Windows driver also doesn't change the rx/tx window sizes when bluetooth gets enabled or disabled, so this is fairly consistent with the Windows driver. Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211103205827.14559-1-verdre@v0yd.nl

mwifiex: Ensure the version string from the firmware is 0-terminated

2021-11-26T16:29:38Z

We assume at a few places that priv->version_str is 0-terminated, but right now we trust the firmware that this is the case with the version string we get from it. Let's rather ensure this ourselves and replace the last character with '\0'. Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211103201800.13531-4-verdre@v0yd.nl

mwifiex: Add quirk to disable deep sleep with certain hardware revision

2021-11-26T16:29:38Z

The 88W8897 PCIe+USB card in the hardware revision 20 apparently has a hardware issue where the card wakes up from deep sleep randomly and very often, somewhat depending on the card activity, maybe the hardware has a floating wakeup pin or something. This was found by comparing two MS Surface Book 2 devices, where one devices wifi card experienced spurious wakeups, while the other one didn't. Those continuous wakeups prevent the card from entering host sleep when the computer suspends. And because the host won't answer to events from the card anymore while it's suspended, the firmwares internal power saving state machine seems to get confused and the card can't sleep anymore at all after that. Since we can't work around that hardware bug in the firmware, let's get the hardware revision string from the firmware and match it with known bad revisions. Then disable auto deep sleep for those revisions, which makes sure we no longer get those spurious wakeups. Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211103201800.13531-3-verdre@v0yd.nl