kernel.git/drivers/net/wireless/rsi, branch linux-4.19.y

wifi: rsi: Do not set MMC_PM_KEEP_POWER in shutdown

2023-08-11T09:45:05Z

[ Upstream commit e74f562328b03fbe9cf438f958464dff3a644dfc ] It makes no sense to set MMC_PM_KEEP_POWER in shutdown. The flag indicates to the MMC subsystem to keep the slot powered on during suspend, but in shutdown the slot should actually be powered off. Drop this call. Fixes: 063848c3e155 ("rsi: sdio: Add WOWLAN support for S5 shutdown state") Signed-off-by: Marek Vasut Reviewed-by: Simon Horman Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230527222859.273768-1-marex@denx.de Signed-off-by: Sasha Levin

rsi: Remove unnecessary boolean condition

2023-06-09T08:24:03Z

commit f613e4803dd6d1f41a86f6406d4c994fa3d387a0 upstream. Clang warns that the address of a pointer will always evaluated as true in a boolean context. drivers/net/wireless/rsi/rsi_91x_mac80211.c:927:50: warning: address of array 'key->key' will always evaluate to 'true' [-Wpointer-bool-conversion] if (vif->type == NL80211_IFTYPE_STATION && key->key && ~~ ~~~~~^~~ 1 warning generated. Link: https://github.com/ClangBuiltLinux/linux/issues/136 Signed-off-by: Nathan Chancellor Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

wifi: rsi: Fix memory leak in rsi_coex_attach()

2023-03-11T15:31:33Z

[ Upstream commit 956fb851a6e19da5ab491e19c1bc323bb2c2cf6f ] The coex_cb needs to be freed when rsi_create_kthread() failed in rsi_coex_attach(). Fixes: 2108df3c4b18 ("rsi: add coex support") Signed-off-by: Yuan Can Reviewed-by: Simon Horman Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221205061441.114632-1-yuancan@huawei.com Signed-off-by: Sasha Levin

wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port

2023-01-18T10:30:10Z

[ Upstream commit b8f6efccbb9dc0ff5dee7e20d69a4747298ee603 ] When using wpa_supplicant v2.10, this driver is no longer able to associate with any AP and fails in the EAPOL 4-way handshake while sending the 2/4 message to the AP. The problem is not present in wpa_supplicant v2.9 or older. The problem stems from HostAP commit 144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available") which changes the way EAPOL frames are sent, from them being send at L2 frames to them being sent via nl80211 control port. An EAPOL frame sent as L2 frame is passed to the WiFi driver with skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control port has skb->protocol set to ETH_P_802_3 . The later happens in ieee80211_tx_control_port(), where the EAPOL frame is encapsulated into 802.3 frame. The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority frames and sends them via highest-priority transmit queue, while the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way handshake frames must be sent as highest-priority, otherwise the 4-way handshake times out. Therefore, to fix this problem, inspect the skb control flags and if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is an EAPOL frame and transmit the frame via high-priority queue just like other ETH_P_PAE frames. Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements") Signed-off-by: Marek Vasut Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221104163339.227432-1-marex@denx.de Signed-off-by: Sasha Levin

rsi: Fix out-of-bounds read in rsi_read_pkt()

2022-01-27T08:04:24Z

[ Upstream commit f1cb3476e48b60c450ec3a1d7da0805bffc6e43a ] rsi_get_* functions rely on an offset variable from usb input. The size of usb input is RSI_MAX_RX_USB_PKT_SIZE(3000), while 2-byte offset can be up to 0xFFFF. Thus a large offset can cause out-of-bounds read. The patch adds a bound checking condition when rcv_pkt_len is 0, indicating it's USB. It's unclear whether this is triggerable from other type of bus. The following check might help in that case. offset > rcv_pkt_len - FRAME_DESC_SZ The bug is trigerrable with conpromised/malfunctioning USB devices. I tested the patch with the crashing input and got no more bug report. Attached is the KASAN report from fuzzing. BUG: KASAN: slab-out-of-bounds in rsi_read_pkt+0x42e/0x500 [rsi_91x] Read of size 2 at addr ffff888019439fdb by task RX-Thread/227 CPU: 0 PID: 227 Comm: RX-Thread Not tainted 5.6.0 #66 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? rsi_read_pkt+0x42e/0x500 [rsi_91x] ? rsi_read_pkt+0x42e/0x500 [rsi_91x] __kasan_report.cold+0x37/0x7c ? rsi_read_pkt+0x42e/0x500 [rsi_91x] kasan_report+0xe/0x20 rsi_read_pkt+0x42e/0x500 [rsi_91x] rsi_usb_rx_thread+0x1b1/0x2fc [rsi_usb] ? rsi_probe+0x16a0/0x16a0 [rsi_usb] ? _raw_spin_lock_irqsave+0x7b/0xd0 ? _raw_spin_trylock_bh+0x120/0x120 ? __wake_up_common+0x10b/0x520 ? rsi_probe+0x16a0/0x16a0 [rsi_usb] kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 Reported-by: Brendan Dolan-Gavitt Signed-off-by: Zekun Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YXxXS4wgu2OsmlVv@10-18-43-117.dynapool.wireless.nyu.edu Signed-off-by: Sasha Levin

rsi: stop thread firstly in rsi_91x_init() error handling

2021-11-26T10:36:10Z

[ 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

rsi: Fix module dev_oper_mode parameter description

2021-11-26T10:36:01Z

commit 31f97cf9f0c31143a2a6fcc89c4a1286ce20157e upstream. The module parameters are missing dev_oper_mode 12, BT classic alone, add it. Moreover, the parameters encode newlines, which ends up being printed malformed e.g. by modinfo, so fix that too. However, the module parameter string is duplicated in both USB and SDIO modules and the dev_oper_mode mode enumeration in those module parameters is a duplicate of macros used by the driver. Furthermore, the enumeration is confusing. So, deduplicate the module parameter string and use __stringify() to encode the correct mode enumeration values into the module parameter string. Finally, replace 'Wi-Fi' with 'Wi-Fi alone' and 'BT' with 'BT classic alone' to clarify what those modes really mean. Fixes: 898b255339310 ("rsi: add module parameter operating mode") Signed-off-by: Marek Vasut Cc: Amitkumar Karwar Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Karun Eagalapati Cc: Martin Fuzzey Cc: Martin Kepplinger Cc: Prameela Rani Garnepudi Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: netdev@vger.kernel.org Cc: # 4.17+ Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210916144245.10181-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman

rsi: fix rate mask set leading to P2P failure

2021-11-26T10:36:01Z

commit b515d097053a71d624e0c5840b42cd4caa653941 upstream. P2P client mode was only working the first time. On subsequent connection attempts the group was successfully created but no data was sent (no transmitted data packets were seen with a sniffer). The reason for this was that the hardware was being configured in fixed rate mode with rate RSI_RATE_1 (1Mbps) which is not valid in the 5GHz band. In P2P mode wpa_supplicant uses NL80211_CMD_SET_TX_BITRATE_MASK to disallow the 11b rates in the 2.4GHz band which updated common->fixedrate_mask. rsi_set_min_rate() then used the fixedrate_mask to calculate the minimum allowed rate, or 0xffff = auto if none was found. However that calculation did not account for the different rate sets allowed in the different bands leading to the error. Fixing set_min_rate() would result in 6Mb/s being used all the time which is not what we want either. The reason the problem did not occur on the first connection is that rsi_mac80211_set_rate_mask() only updated the fixedrate_mask for the *current* band. When it was called that was still 2.4GHz as the switch is done later. So the when set_min_rate() was subsequently called after the switch to 5GHz it still had a mask of zero, leading to defaulting to auto mode. Fix this by differentiating the case of a single rate being requested, in which case the hardware will be used in fixed rate mode with just that rate, and multiple rates being requested, in which case we remain in auto mode but the firmware rate selection algorithm is configured with a restricted set of rates. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman

rsi: fix key enabled check causing unwanted encryption for vap_id > 0

2021-11-26T10:36:01Z

commit 99ac6018821253ec67f466086afb63fc18ea48e2 upstream. My previous patch checked if encryption should be enabled by directly checking info->control.hw_key (like the downstream driver). However that missed that the control and driver_info members of struct ieee80211_tx_info are union fields. Due to this when rsi_core_xmit() updates fields in "tx_params" (driver_info) it can overwrite the control.hw_key, causing the result of the later test to be incorrect. With the current structure layout the first byte of control.hw_key is overlayed with the vap_id so, since we only test if control.hw_key is NULL / non NULL, a non zero vap_id will incorrectly enable encryption. In basic STA and AP modes the vap_id is always zero so it works but in P2P client mode a second VIF is created causing vap_id to be non zero and hence encryption to be enabled before keys have been set. Fix this by extracting the key presence flag to a new field in the driver private tx_params structure and populating it first. Fixes: 314538041b56 ("rsi: fix AP mode with WPA failure due to encrypted EAPOL") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-3-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman

rsi: fix occasional initialisation failure with BT coex

2021-11-26T10:36:01Z

commit 9b14ed6e11b72dd4806535449ca6c6962cb2369d upstream. When BT coexistence is enabled (eg oper mode 13, which is the default) the initialisation on startup sometimes silently fails. In a normal initialisation we see usb 1-1.3: Product: Wireless USB Network Module usb 1-1.3: Manufacturer: Redpine Signals, Inc. usb 1-1.3: SerialNumber: 000000000001 rsi_91x: rsi_probe: Initialized os intf ops rsi_91x: rsi_load_9116_firmware: Loading chunk 0 rsi_91x: rsi_load_9116_firmware: Loading chunk 1 rsi_91x: rsi_load_9116_firmware: Loading chunk 2 rsi_91x: Max Stations Allowed = 1 But sometimes the last log is missing and the wlan net device is not created. Running a userspace loop that resets the hardware via a GPIO shows the problem occurring ~5/100 resets. The problem does not occur in oper mode 1 (wifi only). Adding logs shows that the initialisation state machine requests a MAC reset via rsi_send_reset_mac() but the firmware does not reply, leading to the initialisation sequence being incomplete. Fix this by delaying attaching the BT adapter until the wifi initialisation has completed. With this applied I have done > 300 reset loops with no errors. Fixes: 716b840c7641 ("rsi: handle BT traffic in driver") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman