summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2022-01-27rsi: Fix out-of-bounds read in rsi_read_pkt()Zekun Shen3-1/+6
[ 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 <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YXxXS4wgu2OsmlVv@10-18-43-117.dynapool.wireless.nyu.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27rsi: Fix use-after-free in rsi_rx_done_handler()Zekun Shen1-1/+7
[ Upstream commit b07e3c6ebc0c20c772c0f54042e430acec2945c3 ] When freeing rx_cb->rx_skb, the pointer is not set to NULL, a later rsi_rx_done_handler call will try to read the freed address. This bug will very likley lead to double free, although detected early as use-after-free bug. The bug is triggerable with a compromised/malfunctional usb device. After applying the patch, the same input no longer triggers the use-after-free. Attached is the kasan report from fuzzing. BUG: KASAN: use-after-free in rsi_rx_done_handler+0x354/0x430 [rsi_usb] Read of size 4 at addr ffff8880188e5930 by task modprobe/231 Call Trace: <IRQ> dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] __kasan_report.cold+0x37/0x7c ? dma_direct_unmap_page+0x90/0x110 ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] kasan_report+0xe/0x20 rsi_rx_done_handler+0x354/0x430 [rsi_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __usb_hcd_giveback_urb+0x380/0x380 ? apic_timer_interrupt+0xa/0x20 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 ? handle_irq_event+0xcd/0x157 ? handle_edge_irq+0x1eb/0x7b0 irq_exit+0x114/0x140 do_IRQ+0x91/0x1e0 common_interrupt+0xf/0xf </IRQ> Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YXxQL/vIiYcZUu/j@10-18-43-117.dynapool.wireless.nyu.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27mwifiex: Fix skb_over_panic in mwifiex_usb_recv()Zekun Shen1-1/+2
[ 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:<NULL> 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: <IRQ> ? 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 </IRQ> Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YX4CqjfRcTa6bVL+@Zekuns-MBP-16.fios-router.home Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: Fix crash caused by uninitialized TX ringBaochen Qiang1-2/+0
[ Upstream commit 273703ebdb01b6c5f1aaf4b98fb57b177609055c ] Commit 31582373a4a8 ("ath11k: Change number of TCL rings to one for QCA6390") avoids initializing the other entries of dp->tx_ring cause the corresponding TX rings on QCA6390/WCN6855 are not used, but leaves those ring masks in ath11k_hw_ring_mask_qca6390.tx unchanged. Normally this is OK because we will only get interrupts from the first TX ring on these chips and thus only the first entry of dp->tx_ring is involved. In case of one MSI vector, all DP rings share the same IRQ. For each interrupt, all rings have to be checked, which means the other entries of dp->tx_ring are involved. However since they are not initialized, system crashes. Fix this issue by simply removing those ring masks. crash stack: [ 102.907438] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ 102.907447] #PF: supervisor read access in kernel mode [ 102.907451] #PF: error_code(0x0000) - not-present page [ 102.907453] PGD 1081f0067 P4D 1081f0067 PUD 1081f1067 PMD 0 [ 102.907460] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 102.907465] CPU: 0 PID: 3511 Comm: apt-check Kdump: loaded Tainted: G E 5.15.0-rc4-wt-ath+ #20 [ 102.907470] Hardware name: AMD Celadon-RN/Celadon-RN, BIOS RCD1005E 10/08/2020 [ 102.907472] RIP: 0010:ath11k_dp_tx_completion_handler+0x201/0x830 [ath11k] [ 102.907497] Code: 3c 24 4e 8d ac 37 10 04 00 00 4a 8d bc 37 68 04 00 00 48 89 3c 24 48 63 c8 89 83 84 18 00 00 48 c1 e1 05 48 03 8b 78 18 00 00 <8b> 51 08 89 d6 83 e6 07 89 74 24 24 83 fe 03 74 04 85 f6 75 63 41 [ 102.907501] RSP: 0000:ffff9b7340003e08 EFLAGS: 00010202 [ 102.907505] RAX: 0000000000000001 RBX: ffff8e21530c0100 RCX: 0000000000000020 [ 102.907508] RDX: 0000000000000000 RSI: 00000000fffffe00 RDI: ffff8e21530c1938 [ 102.907511] RBP: ffff8e21530c0000 R08: 0000000000000001 R09: 0000000000000000 [ 102.907513] R10: ffff8e2145534c10 R11: 0000000000000001 R12: ffff8e21530c2938 [ 102.907515] R13: ffff8e21530c18e0 R14: 0000000000000100 R15: ffff8e21530c2978 [ 102.907518] FS: 00007f5d4297e740(0000) GS:ffff8e243d600000(0000) knlGS:0000000000000000 [ 102.907521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.907524] CR2: 0000000000000028 CR3: 00000001034ea000 CR4: 0000000000350ef0 [ 102.907527] Call Trace: [ 102.907531] <IRQ> [ 102.907537] ath11k_dp_service_srng+0x5c/0x2f0 [ath11k] [ 102.907556] ath11k_pci_ext_grp_napi_poll+0x21/0x70 [ath11k_pci] [ 102.907562] __napi_poll+0x2c/0x160 [ 102.907570] net_rx_action+0x251/0x310 [ 102.907576] __do_softirq+0x107/0x2fc [ 102.907585] irq_exit_rcu+0x74/0x90 [ 102.907593] common_interrupt+0x83/0xa0 [ 102.907600] </IRQ> [ 102.907601] asm_common_interrupt+0x1e/0x40 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211026011605.58615-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ar5523: Fix null-ptr-deref with unexpected WDCMSG_TARGET_START replyZekun Shen1-0/+4
[ Upstream commit ae80b6033834342601e99f74f6a62ff5092b1cee ] Unexpected WDCMSG_TARGET_START replay can lead to null-ptr-deref when ar->tx_cmd->odata is NULL. The patch adds a null check to prevent such case. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] ar5523_cmd+0x46a/0x581 [ar5523] ar5523_probe.cold+0x1b7/0x18da [ar5523] ? ar5523_cmd_rx_cb+0x7a0/0x7a0 [ar5523] ? __pm_runtime_set_status+0x54a/0x8f0 ? _raw_spin_trylock_bh+0x120/0x120 ? pm_runtime_barrier+0x220/0x220 ? __pm_runtime_resume+0xb1/0xf0 usb_probe_interface+0x25b/0x710 really_probe+0x209/0x5d0 driver_probe_device+0xc6/0x1b0 device_driver_attach+0xe2/0x120 I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU. After fixing the code (fourth byte in usb packet) to WDCMSG_TARGET_START, I got the null-ptr-deref bug. I believe the bug is triggerable whenever cmd->odata is NULL. After patching, I tested with the same input and no longer see the KASAN report. This was NOT tested on a real device. Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YXsmPQ3awHFLuAj2@10-18-43-117.dynapool.wireless.nyu.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_ftm_rtt_smoothing()Nathan Chancellor1-2/+1
[ Upstream commit 4ccdcc8ffd955490feec05380223db6a48961eb5 ] When building ARCH=arm allmodconfig: drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’: ./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror] 222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ | ^~ drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’ 1070 | do_div(rtt_avg, 100); | ^~~~~~ do_div() has to be used with an unsigned 64-bit integer dividend but rtt_avg is a signed 64-bit integer. div_s64() expects a signed 64-bit integer dividend and signed 32-bit divisor, which fits this scenario, so use that function here to fix the warning. Fixes: 8b0f92549f2c ("iwlwifi: mvm: fix 32-bit build in FTM") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211227191757.2354329-1-nathan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iwlwifi: mvm: test roc running status bits before removing the staNathan Errera1-3/+12
[ Upstream commit 998e1aba6e5eb35370eaf30ccc1823426ec11f90 ] In some cases the sta is being removed twice since we do not test the roc aux running before removing it. Start looking at the bit before removing the sta. Signed-off-by: Nathan Errera <nathan.errera@intel.com> Fixes: 2c2c3647cde4 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iwlwifi: mvm: fix 32-bit build in FTMJohannes Berg1-1/+2
[ Upstream commit 8b0f92549f2c2458200935c12a2e2a6e80234cf5 ] On a 32-bit build, the division here needs to be done using do_div(), otherwise the compiler will try to call a function that doesn't exist, thus failing to build. Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: Fix a NULL pointer dereference in ath11k_mac_op_hw_scan()Zhou Qingyang1-2/+5
[ Upstream commit eccd25136386a04ebf46a64f3a34e8e0fab6d9e1 ] In ath11k_mac_op_hw_scan(), the return value of kzalloc() is directly used in memcpy(), which may lead to a NULL pointer dereference on failure of kzalloc(). Fix this bug by adding a check of arg.extraie.ptr. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_ATH11K=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211202155348.71315-1-zhou1615@umn.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: Fix deleting uninitialized kernel timer during fragment cache flushRameshkumar Sundaram1-1/+1
[ Upstream commit ba53ee7f7f38cf0592b8be1dcdabaf8f7535f8c1 ] frag_timer will be created & initialized for stations when they associate and will be deleted during every key installation while flushing old fragments. For AP interface self peer will be created and Group keys will be installed for this peer, but there will be no real Station entry & hence frag_timer won't be created and initialized, deleting such uninitialized kernel timers causes below warnings and backtraces printed with CONFIG_DEBUG_OBJECTS_TIMERS enabled. [ 177.828008] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0 [ 177.836833] WARNING: CPU: 3 PID: 188 at lib/debugobjects.c:508 debug_print_object+0xb0/0xf0 [ 177.845185] Modules linked in: ath11k_pci ath11k qmi_helpers qrtr_mhi qrtr ns mhi [ 177.852679] CPU: 3 PID: 188 Comm: hostapd Not tainted 5.14.0-rc3-32919-g4034139e1838-dirty #14 [ 177.865805] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 177.871804] pc : debug_print_object+0xb0/0xf0 [ 177.876155] lr : debug_print_object+0xb0/0xf0 [ 177.880505] sp : ffffffc01169b5a0 [ 177.883810] x29: ffffffc01169b5a0 x28: ffffff80081c2320 x27: ffffff80081c4078 [ 177.890942] x26: ffffff8003fe8f28 x25: ffffff8003de9890 x24: ffffffc01134d738 [ 177.898075] x23: ffffffc010948f20 x22: ffffffc010b2d2e0 x21: ffffffc01169b628 [ 177.905206] x20: ffffffc01134d700 x19: ffffffc010c80d98 x18: 00000000000003f6 [ 177.912339] x17: 203a657079742074 x16: 63656a626f202930 x15: 0000000000000152 [ 177.919471] x14: 0000000000000152 x13: 00000000ffffffea x12: ffffffc010d732e0 [ 177.926603] x11: 0000000000000003 x10: ffffffc010d432a0 x9 : ffffffc010d432f8 [ 177.933735] x8 : 000000000002ffe8 x7 : c0000000ffffdfff x6 : 0000000000000001 [ 177.940866] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff [ 177.947997] x2 : ffffffc010c93240 x1 : ffffff80023624c0 x0 : 0000000000000054 [ 177.955130] Call trace: [ 177.957567] debug_print_object+0xb0/0xf0 [ 177.961570] debug_object_assert_init+0x124/0x178 [ 177.966269] try_to_del_timer_sync+0x1c/0x70 [ 177.970536] del_timer_sync+0x30/0x50 [ 177.974192] ath11k_peer_frags_flush+0x34/0x68 [ath11k] [ 177.979439] ath11k_mac_op_set_key+0x1e4/0x338 [ath11k] [ 177.984673] ieee80211_key_enable_hw_accel+0xc8/0x3d0 [ 177.989722] ieee80211_key_replace+0x360/0x740 [ 177.994160] ieee80211_key_link+0x16c/0x210 [ 177.998337] ieee80211_add_key+0x138/0x338 [ 178.002426] nl80211_new_key+0xfc/0x258 [ 178.006257] genl_family_rcv_msg_doit.isra.17+0xd8/0x120 [ 178.011565] genl_rcv_msg+0xd8/0x1c8 [ 178.015134] netlink_rcv_skb+0x38/0xf8 [ 178.018877] genl_rcv+0x34/0x48 [ 178.022012] netlink_unicast+0x174/0x230 [ 178.025928] netlink_sendmsg+0x188/0x388 [ 178.029845] ____sys_sendmsg+0x218/0x250 [ 178.033763] ___sys_sendmsg+0x68/0x90 [ 178.037418] __sys_sendmsg+0x44/0x88 [ 178.040988] __arm64_sys_sendmsg+0x20/0x28 [ 178.045077] invoke_syscall.constprop.5+0x54/0xe0 [ 178.049776] do_el0_svc+0x74/0xc0 [ 178.053084] el0_svc+0x10/0x18 [ 178.056133] el0t_64_sync_handler+0x88/0xb0 [ 178.060310] el0t_64_sync+0x148/0x14c [ 178.063966] ---[ end trace 8a5cf0bf9d34a058 ]--- Add changes to not to delete frag timer for peers during group key installation. Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1 Fixes: c3944a562102 ("ath11k: Clear the fragment cache during key install") Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1639071421-25078-1-git-send-email-quic_ramess@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27mwifiex: Fix possible ABBA deadlockBrian Norris1-2/+6
[ Upstream commit 1b8bb8919ef81bfc8873d223b9361f1685f2106d ] Quoting Jia-Ju Bai <baijiaju1990@gmail.com>: 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 <dianders@chromium.org> Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Link: https://lore.kernel.org/linux-wireless/0e495b14-efbb-e0da-37bd-af6bd677ee2c@gmail.com/ Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YaV0pllJ5p/EuUat@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wireless: iwlwifi: Fix a double free in iwl_txq_dyn_alloc_dmaLv Yunlong1-0/+1
[ Upstream commit f973795a8d19cbf3d03807704eb7c6ff65788d5a ] In iwl_txq_dyn_alloc_dma, txq->tfds is freed at first time by: iwl_txq_alloc()->goto err_free_tfds->dma_free_coherent(). But it forgot to set txq->tfds to NULL. Then the txq->tfds is freed again in iwl_txq_dyn_alloc_dma by: goto error->iwl_txq_gen2_free_memory()->dma_free_coherent(). My patch sets txq->tfds to NULL after the first free to avoid the double free. Fixes: 0cd1ad2d7fd41 ("iwlwifi: move all bus-independent TX functions to common code") Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Link: https://lore.kernel.org/r/20210403054755.4781-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: Use host CE parameters for CE interrupts configurationAnilkumar Kolli1-8/+8
[ Upstream commit b689f091aafd1a874b2f88137934276ab0fca480 ] CE interrupt configuration uses host ce parameters to assign/free interrupts. Use host ce parameters to enable/disable interrupts. This patch fixes below BUG, BUG: KASAN: global-out-of-bounds in 0xffffffbffdfb035c at addr ffffffbffde6eeac Read of size 4 by task kworker/u8:2/132 Address belongs to variable ath11k_core_qmi_firmware_ready+0x1b0/0x5bc [ath11k] OOB is due to ath11k_ahb_ce_irqs_enable() iterates ce_count(which is 12) times and accessing 12th element in target_ce_config (which has only 11 elements) from ath11k_ahb_ce_irq_enable(). With this change host ce configs are used to enable/disable interrupts. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00471-QCAHKSWPL_SILICONZ-1 Fixes: 967c1d1131fa ("ath11k: move target ce configs to hw_params") Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1637249558-12793-1-git-send-email-akolli@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: reset RSN/WPA present state for open BSSKarthikeyan Kathirvel1-0/+4
[ Upstream commit 64bc3aa02ae78b1fcb1b850e0eb1f0622002bfaa ] The ath11k driver is caching the information about RSN/WPA IE in the configured beacon template. The cached information is used during associations to figure out whether 4-way PKT/2-way GTK peer flags need to be set or not. But the code never cleared the state when no such IE was found. This can for example happen when moving from an WPA/RSN to an open setup. The (seemingly connected) peer was then not able to communicate over the link because the firmware assumed a different (encryption enabled) state for the peer. Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: 01e34233c645 ("ath11k: fix wmi peer flags in peer assoc command") Cc: Venkateswara Naralasetty <vnaralas@codeaurora.org> Reported-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Karthikeyan Kathirvel <kathirve@codeaurora.org> [sven@narfation.org: split into separate patches, clean up commit message] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211115100441.33771-2-sven@narfation.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: clear the keys properly via DISABLE_KEYKarthikeyan Kathirvel2-4/+3
[ Upstream commit 436a4e88659842a7cf634d7cc088c8f2cc94ebf5 ] DISABLE_KEY sets the key_len to 0, firmware will not delete the keys if key_len is 0. Changing from security mode to open mode will cause mcast to be still encrypted without vdev restart. Set the proper key_len for DISABLE_KEY cmd to clear the keys in firmware. Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Karthikeyan Kathirvel <kathirve@codeaurora.org> [sven@narfation.org: split into separate patches, clean up commit message] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211115100441.33771-1-sven@narfation.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: Fix ETSI regd with weather radar overlapSven Eckelmann1-47/+56
[ Upstream commit 086c921a354089f209318501038d43c98d3f409f ] Some ETSI countries have a small overlap in the wireless-regdb with an ETSI channel (5590-5650). A good example is Australia: country AU: DFS-ETSI (2400 - 2483.5 @ 40), (36) (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS (5470 - 5600 @ 80), (27), DFS (5650 - 5730 @ 80), (27), DFS (5730 - 5850 @ 80), (36) (57000 - 66000 @ 2160), (43), NO-OUTDOOR If the firmware (or the BDF) is shipped with these rules then there is only a 10 MHz overlap with the weather radar: * below: 5470 - 5590 * weather radar: 5590 - 5600 * above: (none for the rule "5470 - 5600 @ 80") There are several wrong assumption in the ath11k code: * there is always a valid range below the weather radar (actually: there could be no range below the weather radar range OR range could be smaller than 20 MHz) * intersected range in the weather radar range is valid (actually: the range could be smaller than 20 MHz) * range above weather radar is either empty or valid (actually: the range could be smaller than 20 MHz) These wrong assumption will lead in this example to a rule (5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW which is invalid according to is_valid_reg_rule() because the freq_diff is only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a rejection like: WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984 [...] Call trace: [<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211] [<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211] [<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k] [<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k] [<ffffffc0000a93e0>] process_one_work+0x1f8/0x340 [<ffffffc0000a9784>] worker_thread+0x25c/0x448 [<ffffffc0000aedc8>] kthread+0xd0/0xd8 [<ffffffc000085550>] ret_from_fork+0x10/0x40 ath11k c000000.wifi: failed to perform regd update : -22 Invalid regulatory domain detected To avoid this, the algorithm has to be changed slightly. Instead of splitting a rule which overlaps with the weather radar range into 3 pieces and accepting the first two parts blindly, it must actually be checked for each piece whether it is a valid range. And only if it is valid, add it to the output array. When these checks are in place, the processed rules for AU would end up as country AU: DFS-ETSI (2400 - 2483 @ 40), (N/A, 36), (N/A) (5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW (5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW (5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW and will be accepted by the wireless regulatory code. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ath11k: Send PPDU_STATS_CFG with proper pdev mask to firmwareRameshkumar Sundaram2-2/+3
[ Upstream commit 16a2c3d5406f95ef6139de52669c60a39443f5f7 ] HTT_PPDU_STATS_CFG_PDEV_ID bit mask for target FW PPDU stats request message was set as bit 8 to 15. Bit 8 is reserved for soc stats and pdev id starts from bit 9. Hence change the bitmask as bit 9 to 15 and fill the proper pdev id in the request message. In commit 701e48a43e15 ("ath11k: add packet log support for QCA6390"), both HTT_PPDU_STATS_CFG_PDEV_ID and pdev_mask were changed, but this pdev_mask calculation is not valid for platforms which has multiple pdevs with 1 rxdma per pdev, as this is writing same value(i.e. 2) for all pdevs. Hence fixed it to consider pdev_idx as well, to make it compatible for both single and multi pd cases. Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1 Tested on: IPQ6018 hw1.0 WLAN.HK.2.5.0.1-01067-QCAHKSWPL_SILICONZ-1 Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390") Co-developed-by: Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by: Rameshkumar Sundaram <ramess@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210721212029.142388-10-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: fix RX BD rate mapping for 5GHz legacy ratesBenjamin Li1-3/+1
[ Upstream commit cfdf6b19e750f7de8ae71a26932f63b52e3bf74c ] The linear mapping between the BD rate field and the driver's 5GHz legacy rates table (wcn_5ghz_rates) does not only apply for the latter four rates -- it applies to all eight rates. Fixes: 6ea131acea98 ("wcn36xx: Fix warning due to bad rate_idx") Signed-off-by: Benjamin Li <benl@squareup.com> Tested-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211104010548.1107405-3-benl@squareup.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: populate band before determining rate on RXBenjamin Li1-18/+19
[ Upstream commit c9c5608fafe4dae975c9644c7d14c51ad3b0ed73 ] status.band is used in determination of status.rate -- for 5GHz on legacy rates there is a linear shift between the BD descriptor's rate field and the wcn36xx driver's rate table (wcn_5ghz_rates). We have a special clause to populate status.band for hardware scan offload frames. However, this block occurs after status.rate is already populated. Correctly handle this dependency by moving the band block before the rate block. This patch addresses kernel warnings & missing scan results for 5GHz APs that send their beacons/probe responses at the higher four legacy rates (24-54 Mbps), when using hardware scan offload: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4532 ieee80211_rx_napi+0x744/0x8d8 Modules linked in: wcn36xx [...] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.107-g73909fa #1 Hardware name: Square, Inc. T2 (all variants) (DT) Call trace: dump_backtrace+0x0/0x148 show_stack+0x14/0x1c dump_stack+0xb8/0xf0 __warn+0x2ac/0x2d8 warn_slowpath_null+0x44/0x54 ieee80211_rx_napi+0x744/0x8d8 ieee80211_tasklet_handler+0xa4/0xe0 tasklet_action_common+0xe0/0x118 tasklet_action+0x20/0x28 __do_softirq+0x108/0x1ec irq_exit+0xd4/0xd8 __handle_domain_irq+0x84/0xbc gic_handle_irq+0x4c/0xb8 el1_irq+0xe8/0x190 lpm_cpuidle_enter+0x220/0x260 cpuidle_enter_state+0x114/0x1c0 cpuidle_enter+0x34/0x48 do_idle+0x150/0x268 cpu_startup_entry+0x20/0x24 rest_init+0xd4/0xe0 start_kernel+0x398/0x430 ---[ end trace ae28cb759352b403 ]--- Fixes: 8a27ca394782 ("wcn36xx: Correct band/freq reporting on RX") Signed-off-by: Benjamin Li <benl@squareup.com> Tested-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211104010548.1107405-2-benl@squareup.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: Put DXE block into reset before freeing memoryBryan O'Donoghue1-0/+6
[ Upstream commit ed04ea76e69e7194f7489cebe23a32a68f39218d ] When deiniting the DXE hardware we should reset the block to ensure there is no spurious DMA write transaction from the downstream WCNSS to upstream MSM at a skbuff address we will have released. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211105122152.1580542-4-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: Release DMA channel descriptor allocationsBryan O'Donoghue1-0/+5
[ Upstream commit 3652096e5263ad67604b0323f71d133485f410e5 ] When unloading the driver we are not releasing the DMA descriptors which we previously allocated. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211105122152.1580542-3-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: Fix DMA channel enable/disable cycleBryan O'Donoghue1-11/+27
[ Upstream commit 89dcb1da611d9b3ff0728502d58372fdaae9ebff ] Right now we have a broken sequence where we enable DMA channel interrupts which can be left enabled and never disabled if we hit an error path. Worse still when we unload the driver, the DMA channel interrupt bits are left intact. About the only saving grace here is that we do remember to disable the wcnss interrupt when unload the driver. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211105122152.1580542-2-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: Indicate beacon not connection loss on MISSED_BEACON_INDBryan O'Donoghue1-2/+2
[ Upstream commit 588b45c88ae130fe373a8c50edaf54735c3f4fe3 ] Firmware can trigger a missed beacon indication, this is not the same as a lost signal. Flag to Linux the missed beacon and let the WiFi stack decide for itself if the link is up or down by sending its own probe to determine this. We should only be signalling the link is lost when the firmware indicates Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027232529.657764-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27wcn36xx: ensure pairing of init_scan/finish_scan and start_scan/end_scanBenjamin Li3-7/+32
[ Upstream commit 8f1ba8b0ee2679f0b3d22d2a5c1bc70c436fd872 ] An SMD capture from the downstream prima driver on WCN3680B shows the following command sequence for connected scans: - init_scan_req - start_scan_req, channel 1 - end_scan_req, channel 1 - start_scan_req, channel 2 - ... - end_scan_req, channel 3 - finish_scan_req - init_scan_req - start_scan_req, channel 4 - ... - end_scan_req, channel 6 - finish_scan_req - ... - end_scan_req, channel 165 - finish_scan_req Upstream currently never calls wcn36xx_smd_end_scan, and in some cases[1] still sends finish_scan_req twice in a row or before init_scan_req. A typical connected scan looks like this: - init_scan_req - start_scan_req, channel 1 - finish_scan_req - init_scan_req - start_scan_req, channel 2 - ... - start_scan_req, channel 165 - finish_scan_req - finish_scan_req This patch cleans up scanning so that init/finish and start/end are always paired together and correctly nested. - init_scan_req - start_scan_req, channel 1 - end_scan_req, channel 1 - finish_scan_req - init_scan_req - start_scan_req, channel 2 - end_scan_req, channel 2 - ... - start_scan_req, channel 165 - end_scan_req, channel 165 - finish_scan_req Note that upstream will not do batching of 3 active-probe scans before returning to the operating channel, and this patch does not change that. To match downstream in this aspect, adjust IEEE80211_PROBE_DELAY and/or the 125ms max off-channel time in ieee80211_scan_state_decision. [1]: commit d195d7aac09b ("wcn36xx: Ensure finish scan is not requested before start scan") addressed one case of finish_scan_req being sent without a preceding init_scan_req (the case of the operating channel coinciding with the first scan channel); two other cases are: 1) if SW scan is started and aborted immediately, without scanning any channels, we send a finish_scan_req without ever sending init_scan_req, and 2) as SW scan logic always returns us to the operating channel before calling wcn36xx_sw_scan_complete, finish_scan_req is always sent twice at the end of a SW scan Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Benjamin Li <benl@squareup.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027170306.555535-4-benl@squareup.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-20rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with ↵Larry Finger1-0/+1
interrupts enabled commit 8b144dedb928e4e2f433a328d58f44c3c098d63e upstream. Syzbot reports the following WARNING: [200~raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Hardware initialization for the rtl8188cu can run for as long as 350 ms, and the routine may be called with interrupts disabled. To avoid locking the machine for this long, the current routine saves the interrupt flags and enables local interrupts. The problem is that it restores the flags at the end without disabling local interrupts first. This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs"). Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Fixes: a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-16ath11k: Fix buffer overflow when scanning with extraieSven Eckelmann1-3/+3
commit a658c929ded7ea3aee324c8c2a9635a5e5a38e7f upstream. If cfg80211 is providing extraie's for a scanning process then ath11k will copy that over to the firmware. The extraie.len is a 32 bit value in struct element_info and describes the amount of bytes for the vendor information elements. The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This section can have a (payload) length up to 65535 bytes because the WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and could have created a scan request which cannot be parsed correctly by the firmware. But the bigger problem was the allocation of the buffer. It has to align the TLV sections by 4 bytes. But the code was using an u8 to store the newly calculated length of this section (with alignment). And the new calculated length was then used to allocate the skbuff. But the actual code to copy in the data is using the extraie.len and not the calculated "aligned" length. The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled was 264 bytes during tests with a QCA Milan card. But it only allocated 8 bytes (264 bytes % 256) for it. As consequence, the code to memcpy the extraie into the skb was then just overwriting data after skb->end. Things like shinfo were therefore corrupted. This could usually be seen by a crash in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus address). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Cc: stable@vger.kernel.org Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211207142913.1734635-1-sven@narfation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08iwlwifi: mvm: retry init flow if failedMordechay Goodstein5-8/+47
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: <stable@vger.kernel.org> Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08mt76: mt7915: fix NULL pointer dereference in mt7915_get_phy_modeLorenzo Bianconi1-2/+2
commit 6e53d6d26920d5221d3f4d4f5ffdd629ea69aa5c upstream. Fix the following NULL pointer dereference in mt7915_get_phy_mode routine adding an ibss interface to the mt7915 driver. [ 101.137097] wlan0: Trigger new scan to find an IBSS to join [ 102.827039] wlan0: Creating new IBSS network, BSSID 26:a4:50:1a:6e:69 [ 103.064756] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 103.073670] Mem abort info: [ 103.076520] ESR = 0x96000005 [ 103.079614] EC = 0x25: DABT (current EL), IL = 32 bits [ 103.084934] SET = 0, FnV = 0 [ 103.088042] EA = 0, S1PTW = 0 [ 103.091215] Data abort info: [ 103.094104] ISV = 0, ISS = 0x00000005 [ 103.098041] CM = 0, WnR = 0 [ 103.101044] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000460b1000 [ 103.107565] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 103.116590] Internal error: Oops: 96000005 [#1] SMP [ 103.189066] CPU: 1 PID: 333 Comm: kworker/u4:3 Not tainted 5.10.75 #0 [ 103.195498] Hardware name: MediaTek MT7622 RFB1 board (DT) [ 103.201124] Workqueue: phy0 ieee80211_iface_work [mac80211] [ 103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [ 103.212705] pc : mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 103.218103] lr : mt7915_mcu_add_bss_info+0x11c/0x760 [mt7915e] [ 103.223927] sp : ffffffc011cdb9e0 [ 103.227235] x29: ffffffc011cdb9e0 x28: ffffff8006563098 [ 103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40 [ 103.237855] x25: 0000000000000001 x24: 000000000000011f [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918 [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58 [ 103.253785] x19: ffffff8006744400 x18: 0000000000000000 [ 103.259094] x17: 0000000000000000 x16: 0000000000000001 [ 103.264403] x15: 000899c3a2d9d2e4 x14: 000899bdc3c3a1c8 [ 103.269713] x13: 0000000000000000 x12: 0000000000000000 [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000 [ 103.280333] x9 : 0000000000000050 x8 : ffffff8006567d88 [ 103.285642] x7 : ffffff8006563b5c x6 : ffffff8006563b44 [ 103.290952] x5 : 0000000000000002 x4 : 0000000000000001 [ 103.296262] x3 : 0000000000000001 x2 : 0000000000000001 [ 103.301572] x1 : 0000000000000000 x0 : 0000000000000011 [ 103.306882] Call trace: [ 103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 103.314378] mt7915_bss_info_changed+0x198/0x200 [mt7915e] [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211] [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211] [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211] [ 103.337895] ieee80211_ibss_work+0x3dc/0x614 [mac80211] [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211] [ 103.348495] process_one_work+0x288/0x690 [ 103.352499] worker_thread+0x70/0x464 [ 103.356157] kthread+0x144/0x150 [ 103.359380] ret_from_fork+0x10/0x18 [ 103.362952] Code: 394008c3 52800220 394000e4 7100007f (39400023) Fixes: 37f4ca907c46 ("mt76: mt7915: register per-phy HE capabilities for each interface") Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/ddae419a740f1fb9e48afd432035e9f394f512ee.1637239456.git.lorenzo@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08rt2x00: do not mark device gone on EPROTO errors during startStanislaw Gruszka1-0/+3
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 <exuvo@exuvo.se> Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211111141003.GA134627@wp.pl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ath10k: fix invalid dma_addr_t token assignmentArnd Bergmann1-1/+9
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 <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18wcn36xx: Fix discarded frames due to wrong sequence numberLoic Poulain1-2/+7
[ 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 <loic.poulain@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18wcn36xx: add proper DMA memory barriers in rx pathBenjamin Li1-1/+11
[ 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/WCN36