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

mwifiex: Fix skb_over_panic in mwifiex_usb_recv()

2022-01-27T11:02:18Z

[ Upstream commit 04d80663f67ccef893061b49ec8a42ff7045ae84 ] Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev: kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 Reported-by: Brendan Dolan-Gavitt Signed-off-by: Zekun Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YX4CqjfRcTa6bVL+@Zekuns-MBP-16.fios-router.home Signed-off-by: Sasha Levin

mwifiex: Fix possible ABBA deadlock

2022-01-27T11:01:43Z

[ Upstream commit 1b8bb8919ef81bfc8873d223b9361f1685f2106d ] 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 Signed-off-by: Sasha Levin

mwifiex: fix division by zero in fw download path

2021-10-28T13:27:25Z

Add the missing endpoint sanity checks to probe() to avoid division by zero in mwifiex_write_data_sync() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Only add checks for the firmware-download boot stage, which require both command endpoints, for now. The driver looks like it will handle a missing endpoint during normal operation without oopsing, albeit not very gracefully as it will try to submit URBs to the default pipe and fail. Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset") Cc: stable@vger.kernel.org # 3.5 Cc: Amitkumar Karwar Signed-off-by: Johan Hovold Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211027080819.6675-4-johan@kernel.org

libertas: replace snprintf in show functions with sysfs_emit

2021-10-27T07:38:29Z

coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot Signed-off-by: Ye Guojin Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211022090438.1065286-1-ye.guojin@zte.com.cn

libertas: Fix possible memory leak in probe and disconnect

2021-10-27T07:32:21Z

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

libertas_tf: Fix possible memory leak in probe and disconnect

2021-10-27T07:32:21Z

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

wireless: use eth_hw_addr_set() instead of ether_addr_copy()

2021-10-20T09:39:42Z

Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Convert wireless from ether_addr_copy() to eth_hw_addr_set(): @@ expression dev, np; @@ - ether_addr_copy(dev->dev_addr, np) + eth_hw_addr_set(dev, np) Signed-off-by: Jakub Kicinski Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211018235021.1279697-3-kuba@kernel.org

wireless: use eth_hw_addr_set()

2021-10-20T09:39:42Z

Convert all WiFi drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set(): @@ expression dev, np; @@ - memcpy(dev->dev_addr, np, ETH_ALEN) + eth_hw_addr_set(dev, np) Signed-off-by: Jakub Kicinski Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211018235021.1279697-2-kuba@kernel.org

mwifiex: Deactive host sleep using HSCFG after it was activated manually

2021-10-20T08:51:22Z

When powersaving (so either wifi powersaving or deep sleep, depending on which state the firmware is in) is disabled, the way the firmware goes into host sleep is different: Usually the firmware implicitely enters host sleep on the next SLEEP event we get when we configured host sleep via HSCFG before. When powersaving is disabled though, there are no SLEEP events, the way we enter host sleep in that case is different: The firmware will send us a HS_ACT_REQ event and after that we "manually" make the firmware enter host sleep by sending it another HSCFG command with the action HS_ACTIVATE. Now waking up from host sleep appears to be different depending on whether powersaving is enabled again: When powersaving is enabled, the firmware implicitely leaves host sleep as soon as it wakes up and sends us an AWAKE event. When powersaving is disabled though, it apparently doesn't implicitely leave host sleep, but instead we need to send it a HSCFG command with the HS_CONFIGURE action and the HS_CFG_CANCEL condition. We didn't do that so far, which is why waking up from host sleep was broken when powersaving is disabled. So add some additional state to mwifiex_adapter where we keep track of whether host sleep was activated manually via HS_ACTIVATE, and if that was the case, deactivate it manually again via HS_CFG_CANCEL. Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211016153244.24353-6-verdre@v0yd.nl

mwifiex: Send DELBA requests according to spec

2021-10-20T08:51:21Z

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