summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2020-11-05ath11k: change to disable softirqs for ath11k_regd_update to solve deadlockWen Gong1-3/+3
[ Upstream commit df648808c6b9989555e247530d8ca0ad0094b361 ] After base_lock which occupy by ath11k_regd_update, the softirq run for WMI_REG_CHAN_LIST_CC_EVENTID maybe arrived and it also need to accuire the spin lock, then deadlock happend, change to disable softirqis to solve it. [ 235.576990] ================================ [ 235.576991] WARNING: inconsistent lock state [ 235.576993] 5.9.0-rc5-wt-ath+ #196 Not tainted [ 235.576994] -------------------------------- [ 235.576995] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. [ 235.576997] kworker/u16:1/98 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 235.576998] ffff9655f75cad98 (&ab->base_lock){+.?.}-{2:2}, at: ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577009] {IN-SOFTIRQ-W} state was registered at: [ 235.577013] __lock_acquire+0x219/0x6e0 [ 235.577015] lock_acquire+0xb6/0x270 [ 235.577018] _raw_spin_lock+0x2c/0x70 [ 235.577023] ath11k_reg_chan_list_event.isra.0+0x10d/0x1e0 [ath11k] [ 235.577028] ath11k_wmi_tlv_op_rx+0x3c3/0x560 [ath11k] [ 235.577033] ath11k_htc_rx_completion_handler+0x207/0x370 [ath11k] [ 235.577039] ath11k_ce_recv_process_cb+0x15e/0x1e0 [ath11k] [ 235.577041] ath11k_pci_ce_tasklet+0x10/0x30 [ath11k_pci] [ 235.577043] tasklet_action_common.constprop.0+0xd4/0xf0 [ 235.577045] __do_softirq+0xc9/0x482 [ 235.577046] asm_call_on_stack+0x12/0x20 [ 235.577048] do_softirq_own_stack+0x49/0x60 [ 235.577049] irq_exit_rcu+0x9a/0xd0 [ 235.577050] common_interrupt+0xa1/0x190 [ 235.577052] asm_common_interrupt+0x1e/0x40 [ 235.577053] cpu_idle_poll.isra.0+0x2e/0x60 [ 235.577055] do_idle+0x5f/0xe0 [ 235.577056] cpu_startup_entry+0x14/0x20 [ 235.577058] start_kernel+0x443/0x464 [ 235.577060] secondary_startup_64+0xa4/0xb0 [ 235.577061] irq event stamp: 432035 [ 235.577063] hardirqs last enabled at (432035): [<ffffffff968d12b4>] _raw_spin_unlock_irqrestore+0x34/0x40 [ 235.577064] hardirqs last disabled at (432034): [<ffffffff968d10d3>] _raw_spin_lock_irqsave+0x63/0x80 [ 235.577066] softirqs last enabled at (431998): [<ffffffff967115c1>] inet6_fill_ifla6_attrs+0x3f1/0x430 [ 235.577067] softirqs last disabled at (431996): [<ffffffff9671159f>] inet6_fill_ifla6_attrs+0x3cf/0x430 [ 235.577068] [ 235.577068] other info that might help us debug this: [ 235.577069] Possible unsafe locking scenario: [ 235.577069] [ 235.577070] CPU0 [ 235.577070] ---- [ 235.577071] lock(&ab->base_lock); [ 235.577072] <Interrupt> [ 235.577073] lock(&ab->base_lock); [ 235.577074] [ 235.577074] *** DEADLOCK *** [ 235.577074] [ 235.577075] 3 locks held by kworker/u16:1/98: [ 235.577076] #0: ffff9655f75b1d48 ((wq_completion)ath11k_qmi_driver_event){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0 [ 235.577079] #1: ffffa33cc02f3e70 ((work_completion)(&ab->qmi.event_work)){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0 [ 235.577081] #2: ffff9655f75cad50 (&ab->core_lock){+.+.}-{3:3}, at: ath11k_core_qmi_firmware_ready.part.0+0x4e/0x160 [ath11k] [ 235.577087] [ 235.577087] stack backtrace: [ 235.577088] CPU: 3 PID: 98 Comm: kworker/u16:1 Not tainted 5.9.0-rc5-wt-ath+ #196 [ 235.577089] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 235.577095] Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work [ath11k] [ 235.577096] Call Trace: [ 235.577100] dump_stack+0x77/0xa0 [ 235.577102] mark_lock_irq.cold+0x15/0x3c [ 235.577104] mark_lock+0x1d7/0x540 [ 235.577105] mark_usage+0xc7/0x140 [ 235.577107] __lock_acquire+0x219/0x6e0 [ 235.577108] ? sched_clock_cpu+0xc/0xb0 [ 235.577110] lock_acquire+0xb6/0x270 [ 235.577116] ? ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577118] ? atomic_notifier_chain_register+0x2d/0x40 [ 235.577120] _raw_spin_lock+0x2c/0x70 [ 235.577125] ? ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577130] ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577136] __ath11k_mac_register+0x3fb/0x480 [ath11k] [ 235.577141] ath11k_mac_register+0x119/0x180 [ath11k] [ 235.577146] ath11k_core_pdev_create+0x17/0xe0 [ath11k] [ 235.577150] ath11k_core_qmi_firmware_ready.part.0+0x65/0x160 [ath11k] [ 235.577155] ath11k_qmi_driver_event_work+0x1c5/0x230 [ath11k] [ 235.577158] process_one_work+0x265/0x5d0 [ 235.577160] worker_thread+0x49/0x300 [ 235.577161] ? process_one_work+0x5d0/0x5d0 [ 235.577163] kthread+0x135/0x150 [ 235.577164] ? kthread_create_worker_on_cpu+0x60/0x60 [ 235.577166] ret_from_fork+0x22/0x30 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-7-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05ath11k: fix warning caused by lockdep_assert_heldCarl Huang1-0/+4
[ Upstream commit 2f588660e34a982377109872757f1b99d7748d21 ] Fix warning caused by lockdep_assert_held when CONFIG_LOCKDEP is enabled. [ 271.940647] WARNING: CPU: 6 PID: 0 at drivers/net/wireless/ath/ath11k/hal.c:818 ath11k_hal_srng_access_begin+0x31/0x40 [ath11k] [ 271.940655] Modules linked in: qrtr_mhi qrtr ns ath11k_pci mhi ath11k qmi_helpers nvme nvme_core [ 271.940675] CPU: 6 PID: 0 Comm: swapper/6 Kdump: loaded Tainted: G W 5.9.0-rc5-kalle-bringup-wt-ath+ #4 [ 271.940682] Hardware name: Dell Inc. Inspiron 7590/08717F, BIOS 1.3.0 07/22/2019 [ 271.940698] RIP: 0010:ath11k_hal_srng_access_begin+0x31/0x40 [ath11k] [ 271.940708] Code: 48 89 f3 85 c0 75 11 48 8b 83 a8 00 00 00 8b 00 89 83 b0 00 00 00 5b c3 48 8d 7e 58 be ff ff ff ff e8 53 24 ec fa 85 c0 75 dd <0f> 0b eb d9 90 66 2e 0f 1f 84 00 00 00 00 00 55 53 48 89 f3 8b 35 [ 271.940718] RSP: 0018:ffffbdf0c0230df8 EFLAGS: 00010246 [ 271.940727] RAX: 0000000000000000 RBX: ffffa12b34e67680 RCX: ffffa12b57a0d800 [ 271.940735] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffa12b34e676d8 [ 271.940742] RBP: ffffa12b34e60000 R08: 0000000000000001 R09: 0000000000000001 [ 271.940753] R10: 0000000000000001 R11: 0000000000000046 R12: 0000000000000000 [ 271.940763] R13: ffffa12b34e60000 R14: ffffa12b34e60000 R15: 0000000000000000 [ 271.940774] FS: 0000000000000000(0000) GS:ffffa12b5a400000(0000) knlGS:0000000000000000 [ 271.940788] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 271.940798] CR2: 00007f8bef282008 CR3: 00000001f4224004 CR4: 00000000003706e0 [ 271.940805] Call Trace: [ 271.940813] <IRQ> [ 271.940835] ath11k_dp_tx_completion_handler+0x9e/0x950 [ath11k] [ 271.940847] ? lock_acquire+0xba/0x3b0 [ 271.940876] ath11k_dp_service_srng+0x5a/0x2e0 [ath11k] [ 271.940893] ath11k_pci_ext_grp_napi_poll+0x1e/0x80 [ath11k_pci] [ 271.940908] net_rx_action+0x283/0x4f0 [ 271.940931] __do_softirq+0xcb/0x499 [ 271.940950] asm_call_on_stack+0x12/0x20 [ 271.940963] </IRQ> [ 271.940979] do_softirq_own_stack+0x4d/0x60 [ 271.940991] irq_exit_rcu+0xb0/0xc0 [ 271.941001] common_interrupt+0xce/0x190 [ 271.941014] asm_common_interrupt+0x1e/0x40 [ 271.941026] RIP: 0010:cpuidle_enter_state+0x115/0x500 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601463073-12106-5-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05ath11k: Use GFP_ATOMIC instead of GFP_KERNEL in ath11k_dp_htt_get_ppdu_descWen Gong1-1/+1
[ Upstream commit 6a8be1baa9116a038cb4f6158cc10134387ca0d0 ] With SLUB DEBUG CONFIG below crash is seen as kmem_cache_alloc is being called in non-atomic context. To fix this issue, use GFP_ATOMIC instead of GFP_KERNEL kzalloc. [ 357.217088] BUG: sleeping function called from invalid context at mm/slab.h:498 [ 357.217091] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0 [ 357.217092] INFO: lockdep is turned off. [ 357.217095] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.9.0-rc5-wt-ath+ #196 [ 357.217096] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 357.217097] Call Trace: [ 357.217098] <IRQ> [ 357.217107] ? ath11k_dp_htt_get_ppdu_desc+0xa9/0x170 [ath11k] [ 357.217110] dump_stack+0x77/0xa0 [ 357.217113] ___might_sleep.cold+0xa6/0xb6 [ 357.217116] kmem_cache_alloc_trace+0x1f2/0x270 [ 357.217122] ath11k_dp_htt_get_ppdu_desc+0xa9/0x170 [ath11k] [ 357.217129] ath11k_htt_pull_ppdu_stats.isra.0+0x96/0x270 [ath11k] [ 357.217135] ath11k_dp_htt_htc_t2h_msg_handler+0xe7/0x1d0 [ath11k] [ 357.217137] ? trace_hardirqs_on+0x1c/0x100 [ 357.217143] ath11k_htc_rx_completion_handler+0x207/0x370 [ath11k] [ 357.217149] ath11k_ce_recv_process_cb+0x15e/0x1e0 [ath11k] [ 357.217151] ? handle_irq_event+0x70/0xa8 [ 357.217154] ath11k_pci_ce_tasklet+0x10/0x30 [ath11k_pci] [ 357.217157] tasklet_action_common.constprop.0+0xd4/0xf0 [ 357.217160] __do_softirq+0xc9/0x482 [ 357.217162] asm_call_on_stack+0x12/0x20 [ 357.217163] </IRQ> [ 357.217166] do_softirq_own_stack+0x49/0x60 [ 357.217167] irq_exit_rcu+0x9a/0xd0 [ 357.217169] common_interrupt+0xa1/0x190 [ 357.217171] asm_common_interrupt+0x1e/0x40 [ 357.217173] RIP: 0010:cpu_idle_poll.isra.0+0x2e/0x60 [ 357.217175] Code: 8b 35 26 27 74 69 e8 11 c8 3d ff e8 bc fa 42 ff e8 e7 9f 4a ff fb 65 48 8b 1c 25 80 90 01 00 48 8b 03 a8 08 74 0b eb 1c f3 90 <48> 8b 03 a8 08 75 13 8b 0 [ 357.217177] RSP: 0018:ffffffff97403ee0 EFLAGS: 00000202 [ 357.217178] RAX: 0000000000000001 RBX: ffffffff9742b8c0 RCX: 0000000000b890ca [ 357.217180] RDX: 0000000000b890ca RSI: 0000000000000001 RDI: ffffffff968d0c49 [ 357.217181] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 [ 357.217182] R10: ffffffff9742b8c0 R11: 0000000000000046 R12: 0000000000000000 [ 357.217183] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000066fdf520 [ 357.217186] ? cpu_idle_poll.isra.0+0x19/0x60 [ 357.217189] do_idle+0x5f/0xe0 [ 357.217191] cpu_startup_entry+0x14/0x20 [ 357.217193] start_kernel+0x443/0x464 [ 357.217196] secondary_startup_64+0xa4/0xb0 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-8-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05brcmfmac: Fix warning message after dongle setup failedWright Feng1-4/+6
[ Upstream commit 6aa5a83a7ed8036c1388a811eb8bdfa77b21f19c ] Brcmfmac showed warning message in fweh.c when checking the size of event queue which is not initialized. Therefore, we only cancel the worker and reset event handler only when it is initialized. [ 145.505899] brcmfmac 0000:02:00.0: brcmf_pcie_setup: Dongle setup [ 145.929970] ------------[ cut here ]------------ [ 145.929994] WARNING: CPU: 0 PID: 288 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c:312 brcmf_fweh_detach+0xbc/0xd0 [brcmfmac] ... [ 145.930029] Call Trace: [ 145.930036] brcmf_detach+0x77/0x100 [brcmfmac] [ 145.930043] brcmf_pcie_remove+0x79/0x130 [brcmfmac] [ 145.930046] pci_device_remove+0x39/0xc0 [ 145.930048] device_release_driver_internal+0x141/0x200 [ 145.930049] device_release_driver+0x12/0x20 [ 145.930054] brcmf_pcie_setup+0x101/0x3c0 [brcmfmac] [ 145.930060] brcmf_fw_request_done+0x11d/0x1f0 [brcmfmac] [ 145.930062] ? lock_timer_base+0x7d/0xa0 [ 145.930063] ? internal_add_timer+0x1f/0xa0 [ 145.930064] ? add_timer+0x11a/0x1d0 [ 145.930066] ? __kmalloc_track_caller+0x18c/0x230 [ 145.930068] ? kstrdup_const+0x23/0x30 [ 145.930069] ? add_dr+0x46/0x80 [ 145.930070] ? devres_add+0x3f/0x50 [ 145.930072] ? usermodehelper_read_unlock+0x15/0x20 [ 145.930073] ? _request_firmware+0x288/0xa20 [ 145.930075] request_firmware_work_func+0x36/0x60 [ 145.930077] process_one_work+0x144/0x360 [ 145.930078] worker_thread+0x4d/0x3c0 [ 145.930079] kthread+0x112/0x150 [ 145.930080] ? rescuer_thread+0x340/0x340 [ 145.930081] ? kthread_park+0x60/0x60 [ 145.930083] ret_from_fork+0x25/0x30 Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928054922.44580-3-wright.feng@cypress.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05brcmfmac: increase F2 watermark for BCM4329Dmitry Osipenko1-0/+1
[ Upstream commit 317da69d10b0247c4042354eb90c75b81620ce9d ] This patch fixes SDHCI CRC errors during of RX throughput testing on BCM4329 chip if SDIO BUS is clocked above 25MHz. In particular the checksum problem is observed on NVIDIA Tegra20 SoCs. The good watermark value is borrowed from downstream BCMDHD driver and it's matching to the value that is already used for the BCM4339 chip, hence let's re-use it for BCM4329. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200830191439.10017-2-digetx@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05ath10k: fix VHT NSS calculation when STBC is enabledSathishkumar Muruganandam1-1/+7
[ Upstream commit 99f41b8e43b8b4b31262adb8ac3e69088fff1289 ] When STBC is enabled, NSTS_SU value need to be accounted for VHT NSS calculation for SU case. Without this fix, 1SS + STBC enabled case was reported wrongly as 2SS in radiotap header on monitor mode capture. Tested-on: QCA9984 10.4-3.10-00047 Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1597392971-3897-1-git-send-email-murugana@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05ath10k: start recovery process when payload length exceeds max htc length ↵Wen Gong1-0/+4
for sdio [ Upstream commit 2fd3c8f34d08af0a6236085f9961866ad92ef9ec ] When simulate random transfer fail for sdio write and read, it happened "payload length exceeds max htc length" and recovery later sometimes. Test steps: 1. Add config and update kernel: CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y 2. Run simulate fail: cd /sys/kernel/debug/mmc1/fail_mmc_request echo 10 > probability echo 10 > times # repeat until hitting issues 3. It happened payload length exceeds max htc length. [ 199.935506] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 .... [ 264.990191] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 4. after some time, such as 60 seconds, it start recovery which triggered by wmi command timeout for periodic scan. [ 269.229232] ieee80211 phy0: Hardware restart was requested [ 269.734693] ath10k_sdio mmc1:0001:1: device successfully recovered The simulate fail of sdio is not a real sdio transter fail, it only set an error status in mmc_should_fail_request after the transfer end, actually the transfer is success, then sdio_io_rw_ext_helper will return error status and stop transfer the left data. For example, the really RX len is 286 bytes, then it will split to 2 blocks in sdio_io_rw_ext_helper, one is 256 bytes, left is 30 bytes, if the first 256 bytes get an error status by mmc_should_fail_request,then the left 30 bytes will not read in this RX operation. Then when the next RX arrive, the left 30 bytes will be considered as the header of the read, the top 4 bytes of the 30 bytes will be considered as lookaheads, but actually the 4 bytes is not the lookaheads, so the len from this lookaheads is not correct, it exceeds max htc length 4088 sometimes. When happened exceeds, the buffer chain is not matched between firmware and ath10k, then it need to start recovery ASAP. Recently then recovery will be started by wmi command timeout, but it will be long time later, for example, it is 60+ seconds later from the periodic scan, if it does not have periodic scan, it will be longer. Start recovery when it happened "payload length exceeds max htc length" will be reasonable. This patch only effect sdio chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200108031957.22308-3-wgong@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05ath10k: fix retry packets update in station dumpVenkateswara Naralasetty2-5/+8
[ Upstream commit 67b927f9820847d30e97510b2f00cd142b9559b6 ] When tx status enabled, retry count is updated from tx completion status. which is not working as expected due to firmware limitation where firmware can not provide per MSDU rate statistics from tx completion status. Due to this tx retry count is always 0 in station dump. Fix this issue by updating the retry packet count from per peer statistics. This patch will not break on SDIO devices since, this retry count is already updating from peer statistics for SDIO devices. Tested-on: QCA9984 PCI 10.4-3.6-00104 Tested-on: QCA9882 PCI 10.2.4-1.0-00047 Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1591856446-26977-1-git-send-email-vnaralas@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-01p54: avoid accessing the data mapped to streaming DMAJia-Ju Bai1-1/+3
commit 478762855b5ae9f68fa6ead1edf7abada70fcd5f upstream. In p54p_tx(), skb->data is mapped to streaming DMA on line 337: mapping = pci_map_single(..., skb->data, ...); Then skb->data is accessed on line 349: desc->device_addr = ((struct p54_hdr *)skb->data)->req_id; This access may cause data inconsistency between CPU cache and hardware. To fix this problem, ((struct p54_hdr *)skb->data)->req_id is stored in a local variable before DMA mapping, and then the driver accesses this local variable instead of skb->data. Cc: <stable@vger.kernel.org> Signed-off-by: Jia-Ju Bai <baijiaju@tsinghua.edu.cn> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802132949.26788-1-baijiaju@tsinghua.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n()Zekun Shen1-0/+8
[ Upstream commit bad60b8d1a7194df38fd7fe4b22f3f4dcf775099 ] The idx in __ath10k_htt_rx_ring_fill_n function lives in consistent dma region writable by the device. Malfunctional or malicious device could manipulate such idx to have a OOB write. Either by htt->rx_ring.netbufs_ring[idx] = skb; or by ath10k_htt_set_paddrs_ring(htt, paddr, idx); The idx can also be negative as it's signed, giving a large memory space to write to. It's possibly exploitable by corruptting a legit pointer with a skb pointer. And then fill skb with payload as rougue object. Part of the log here. Sometimes it appears as UAF when writing to a freed memory by chance. [ 15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0 [ 15.595483] #PF: supervisor write access in kernel mode [ 15.596250] #PF: error_code(0x0002) - not-present page [ 15.597013] PGD 0 P4D 0 [ 15.597395] Oops: 0002 [#1] SMP KASAN PTI [ 15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69 [ 15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcm80211: fix possible memleak in brcmf_proto_msgbuf_attachWang Yufen1-0/+2
[ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ] When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL, we should destroy the workqueue. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: don't call del_timer_sync() on uninitialized timerTetsuo Handa1-1/+2
[ Upstream commit 621a3a8b1c0ecf16e1e5667ea5756a76a082b738 ] syzbot is reporting that del_timer_sync() is called from mwifiex_usb_cleanup_tx_aggr() from mwifiex_unregister_dev() without checking timer_setup() from mwifiex_usb_tx_init() was called [1]. Ganapathi Bhat proposed a possibly cleaner fix, but it seems that that fix was forgotten [2]. "grep -FrB1 'del_timer' drivers/ | grep -FA1 '.function)'" says that currently there are 28 locations which call del_timer[_sync]() only if that timer's function field was initialized (because timer_setup() sets that timer's function field). Therefore, let's use same approach here. [1] https://syzkaller.appspot.com/bug?id=26525f643f454dd7be0078423e3cdb0d57744959 [2] https://lkml.kernel.org/r/CA+ASDXMHt2gq9Hy+iP_BYkWXsSreWdp3_bAfMkNcuqJ3K+-jbQ@mail.gmail.com Reported-by: syzbot <syzbot+dc4127f950da51639216@syzkaller.appspotmail.com> Cc: Ganapathi Bhat <ganapathi.bhat@nxp.com> Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Brian Norris <briannorris@chromium.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200821082720.7716-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtl8xxxu: prevent potential memory leakChris Chiu1-1/+9
[ Upstream commit 86279456a4d47782398d3cb8193f78f672e36cac ] Free the skb if usb_submit_urb fails on rx_urb. And free the urb no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200906040424.22022-1-chiu@endlessm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcmsmac: fix memory leak in wlc_phy_attach_lcnphyKeita Suzuki1-1/+3
[ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ] When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy, the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be freed in the caller function. Fix this by calling wlc_phy_detach_lcnphy in the error handler of wlc_phy_txpwr_srom_read_lcnphy before returning. Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath9k: hif_usb: fix race condition between usb_get_urb() and ↵Brooke Basile1-0/+19
usb_kill_anchored_urbs() [ Upstream commit 03fb92a432ea5abe5909bca1455b7e44a9380480 ] Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor systems create a race condition in which usb_kill_anchored_urbs() deallocates the URB before the completer callback is called in usb_kill_urb(), resulting in a use-after-free. To fix this, add proper lock protection to usb_kill_urb() calls that can possibly run concurrently with usb_kill_anchored_urbs(). Reported-by: syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf Signed-off-by: Brooke Basile <brookebasile@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200911071427.32354-1-brookebasile@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7915: do not do any work in napi poll after calling napi_complete_done()Felix Fietkau1-6/+3
[ Upstream commit 38b04398c532e9bb9aa90fc07846ad0b0845fe94 ] Fixes a race condition where multiple tx cleanup or sta poll tasks could run in parallel. Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: increse the size of rx buffer sizeTzu-En Huang1-2/+2
[ Upstream commit ee755732b7a16af018daa77d9562d2493fb7092f ] The vht capability of MAX_MPDU_LENGTH is 11454 in rtw88; however, the rx buffer size for each packet is 8192. When receiving packets that are larger than rx buffer size, it will leads to rx buffer ring overflow. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925061219.23754-2-tehuang@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: pci: Power cycle device during shutdownKai-Heng Feng1-0/+2
[ Upstream commit 44492e70adc8086c42d3745d21d591657a427f04 ] There are reports that 8822CE fails to work rtw88 with "failed to read DBI register" error. Also I have a system with 8723DE which freezes the whole system when the rtw88 is probing the device. According to [1], platform firmware may not properly power manage the device during shutdown. I did some expirements and putting the device to D3 can workaround the issue. So let's power cycle the device by putting the device to D3 at shutdown to prevent the issue from happening. [1] https://bugzilla.kernel.org/show_bug.cgi?id=206411#c9 BugLink: https://bugs.launchpad.net/bugs/1872984 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928165508.20775-1-kai.heng.feng@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: fix double freeTom Rix1-0/+2
[ Upstream commit 53708f4fd9cfe389beab5c8daa763bcd0e0b4aef ] clang static analysis reports this problem: sdio.c:2403:3: warning: Attempt to free released memory kfree(card->mpa_rx.buf); ^~~~~~~~~~~~~~~~~~~~~~~ When mwifiex_init_sdio() fails in its first call to mwifiex_alloc_sdio_mpa_buffer, it falls back to calling it again. If the second alloc of mpa_tx.buf fails, the error handler will try to free the old, previously freed mpa_rx.buf. Reviewing the code, it looks like a second double free would happen with mwifiex_cleanup_sdio(). So set both pointers to NULL when they are freed. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201004131931.29782-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: dbg: run init_cfg function once per driver loadMordechay Goodstein1-0/+3
[ Upstream commit 42f8a2735cc218b6b372134684d4cd3c1423f123 ] Every time we call init_cfg driver appends the enabled triggers to the active triggers while this should be done only once per driver load. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.79bd622e604a.Ie0f79d2ea90ca5cdf363f56194ead81b0a2c6202@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: dbg: remove no filter conditionMordechay Goodstein1-3/+2
[ Upstream commit bfdb157127dab2a85d4096a68a00ad568c9eb590 ] Currently if group-id and command-id values are zero we trigger and collect every RX frame, this is not the right behavior and zero value should be handled like any other filter. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: 3ed34fbf9d3b ("iwlwifi: dbg_ini: support FW response/notification region type") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.6a0aae2c0507.I7bd72968279d586af420472707d53106b35efc08@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: mvm: split a print to avoid a WARNING in ROCEmmanuel Grumbach1-3/+6
[ Upstream commit 903b3f9badf1d54f77b468b96706dab679b45b14 ] A print in the remain on channel code was too long and caused a WARNING, split it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: dc28e12f2125 ("iwlwifi: mvm: ROC: Extend the ROC max delay duration & limit ROC duration") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930102759.58d57c0bdc68.Ib06008665e7bf1199c360aa92691d9c74fb84990@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29qtnfmac: fix resource leaks on unsupported iftype error return pathColin Ian King1-0/+2
[ Upstream commit 63f6982075d890d7563e2469643f05a37d193f01 ] Currently if an unsupported iftype is detected the error return path does not free the cmd_skb leading to a resource leak. Fix this by free'ing cmd_skb. Addresses-Coverity: ("Resource leak") Fixes: 805b28c05c8e ("qtnfmac: prepare for AP_VLAN interface type support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925132224.21638-1-colin.king@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7915: fix possible memory leak in mt7915_mcu_add_beaconLorenzo Bianconi1-8/+10
[ Upstream commit 071c8ce8e92a86b8bf78678e78eb4b79fdc16768 ] Release mcu message memory in case of failure in mt7915_mcu_add_beacon routine Fixes: e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7622: fix fw hang on mt7622Lorenzo Bianconi1-14/+32
[ Upstream commit 6892555dbe71ed551d3779aa20747484dc9b6ad5 ] Set poll timeout to 3s for mt7622 devices in order to avoid fw hangs. Swap mt7622_trigger_hif_int and doorbell configuration order in mt7615_mcu_drv_pmctrl routine. Introduce mt7615_mcu_lp_drv_pmctrl routine to take care of drv_own configuration for runtime-pm. Fixes: 08523a2a1db5 ("mt76: mt7615: add mt7615_pm_wake utility routine") Fixes: 894b7767ec2f ("mt76: mt7615: improve mt7615_driver_own reliability") Fixes: 757b0e7fd6f4 ("mt76: mt7615: avoid polling in fw_own for mt7663") Co-developed-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7615: move drv_own/fw_own in mt7615_mcu_opsLorenzo Bianconi4-83/+89
[ Upstream commit 186b659c0859704ef3b2fb634a659724f020889a ] Introduce set_drv_ctrl and set_fw_ctrl function pointers in mt7615_mcu_ops data structure. This is a preliminary patch to enable runtime-pm for non-pci chipsets Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7663u: fix dma header initializationLorenzo Bianconi2-3/+8
[ Upstream commit 8da40d698111ad27b03afc40d67843e3073395e7 ] Fix length field corruption in usb dma header introduced adding sdio support Fixes: 75b10f0cbd0b ("mt76: mt76u: add mt76_skb_adjust_pad utility routine") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: fix a possible NULL pointer dereference in mt76_testmode_dumpLorenzo Bianconi1-2/+6
[ Upstream commit ce8463a726a5669b200a1c2c17f95bc1394cc6bf ] Fix a possible NULL pointer dereference in mt76_testmode_dump() since nla_nest_start returns NULL in case of error Fixes: f0efa8621550e ("mt76: add API for testmode support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7615: fix a possible NULL pointer dereference in mt7615_pm_wake_workLorenzo Bianconi1-1/+2
[ Upstream commit a081de174d11b12db9a94eb748041c2732f14c10 ] Initialize wcid to global_wcid if msta is NULL in mt7615_pm_wake_work routine since wcid will be dereferenced running mt76_tx() Fixes: 2b8cdfb28d340 ("mt76: mt7615: wake device before pushing frames in mt7615_tx") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7615: fix possible memory leak in mt7615_tm_set_tx_powerLorenzo Bianconi1-2/+4
[ Upstream commit e862825dcf74203c5ab60335c341766808f47507 ] Fix a memory leak in mt7615_tm_set_tx_power routine if mt7615_eeprom_get_target_power_index fails. Moreover do not account req_header twice in mcu skb allocation. Fixes: 4f0bce1c88882 ("mt76: mt7615: implement testmode support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7663s: fix resume failureSean Wang1-0/+2
[ Upstream commit 8b7c6e1cb2cb1d4e2ee94556695d80dde6ccdcc6 ] MT7663s have to rely on MMC_PM_KEEP_POWER in pm_flags for to avoid SDIO power is being shut off. To fix sdio access failure like "mt7663s mmc1:0001:1: sdio write failed: -22" for the first sdio command to access the bus in the resume handler. Fixes: a66cbdd6573d ("mt76: mt7615: introduce mt7663s support") Co-developed-by: YN Chen <YN.Chen@mediatek.com> Signed-off-by: YN Chen <YN.Chen@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7615: release mutex in mt7615_reset_test_setLorenzo Bianconi1-3/+2
[ Upstream commit 346f810e22428cdf73ee5cf2e0ce1b79d5671de5 ] Reduce scope of mutex_acquire/mutex_release in mt7615_reset_test_set routine in order to fix the following static checker warning: drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c:179 mt7615_reset_test_set() warn: inconsistent returns 'dev->mt76.mutex'. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: ea4906c4be49 ("mt76: mt7615: wake device before accessing regmap in debugfs") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7615: hold mt76 lock queueing wd in mt7615_queue_key_updateLorenzo Bianconi1-0/+3
[ Upstream commit cddaaa56375615c256eb6960d3092ddb8a7a9154 ] wq queue is always updated holding mt76 spinlock. Grab mt76 lock in mt7615_queue_key_update() before putting a new element at the end of the queue. Fixes: eb99cc95c3b65 ("mt76: mt7615: introduce mt7663u support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: Fix potential probe error handling race with wow firmware loadingAndreas Färber1-0/+3
[ Upstream commit ac4bac99161e8f7a7a9faef70d8ca8f69d5493a9 ] If rtw_core_init() fails to load the wow firmware, rtw_core_deinit() will not get called to clean up the regular firmware. Ensure that an error loading the wow firmware does not produce an oops for the regular firmware by waiting on its completion to be signalled before returning. Also release the loaded firmware. Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Chin-Yen Lee <timlee@realtek.com> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200920132621.26468-3-afaerber@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: Fix probe error handling race with firmware loadingAndreas Färber1-0/+2
[ Upstream commit ecda9cda3338b594a1b82d62018c247132a39e57 ] In case of rtw8822be, a probe failure after successful rtw_core_init() has been observed to occasionally lead to an oops from rtw_load_firmware_cb(): [ 3.924268] pci 0001:01:00.0: [10ec:b822] type 00 class 0xff0000 [ 3.930531] pci 0001:01:00.0: reg 0x10: [io 0x0000-0x00ff] [ 3.936360] pci 0001:01:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit] [ 3.944042] pci 0001:01:00.0: supports D1 D2 [ 3.948438] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 3.957312] pci 0001:01:00.0: BAR 2: no space for [mem size 0x00010000 64bit] [ 3.964645] pci 0001:01:00.0: BAR 2: failed to assign [mem size 0x00010000 64bit] [ 3.972332] pci 0001:01:00.0: BAR 0: assigned [io 0x10000-0x100ff] [ 3.986240] rtw_8822be 0001:01:00.0: enabling device (0000 -> 0001) [ 3.992735] rtw_8822be 0001:01:00.0: failed to map pci memory [ 3.998638] rtw_8822be 0001:01:00.0: failed to request pci io region [ 4.005166] rtw_8822be 0001:01:00.0: failed to setup pci resources [ 4.011580] rtw_8822be: probe of 0001:01:00.0 failed with error -12 [ 4.018827] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 4.029121] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 4.050828] Unable to handle kernel paging request at virtual address edafeaac9607952c [ 4.058975] Mem abort info: [ 4.058980] ESR = 0x96000004 [ 4.058990] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.070353] SET = 0, FnV = 0 [ 4.073487] EA = 0, S1PTW = 0 [ 4.073501] dw-apb-uart 98007800.serial: forbid DMA for kernel console [ 4.076723] Data abort info: [ 4.086415] ISV = 0, ISS = 0x00000004 [ 4.087731] Freeing unused kernel memory: 1792K [ 4.090391] CM = 0, WnR = 0 [ 4.098091] [edafeaac9607952c] address between user and kernel address ranges [ 4.105418] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 4.111129] Modules linked in: [ 4.114275] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.9.0-rc5-next-20200915+ #700 [ 4.122386] Hardware name: Realtek Saola EVB (DT) [ 4.127223] Workqueue: events request_firmware_work_func [ 4.132676] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) [ 4.138393] pc : rtw_load_firmware_cb+0x54/0xbc [ 4.143040] lr : request_firmware_work_func+0x44/0xb4 [ 4.148217] sp : ffff800010133d70 [ 4.151616] x29: ffff800010133d70 x28: 0000000000000000 [ 4.157069] x27: 0000000000000000 x26: 0000000000000000 [ 4.162520] x25: 0000000000000000 x24: 0000000000000000 [ 4.167971] x23: ffff00007ac21908 x22: ffff00007ebb2100 [ 4.173424] x21: ffff00007ad35880 x20: edafeaac96079504 [ 4.178877] x19: ffff00007ad35870 x18: 0000000000000000 [ 4.184328] x17: 00000000000044d8 x16: 0000000000004310 [ 4.189780] x15: 0000000000000800 x14: 00000000ef006305 [ 4.195231] x13: ffffffff00000000 x12: ffffffffffffffff [ 4.200682] x11: 0000000000000020 x10: 0000000000000003 [ 4.206135] x9 : 0000000000000000 x8 : ffff00007e73f680 [ 4.211585] x7 : 0000000000000000 x6 : ffff80001119b588 [ 4.217036] x5 : ffff00007e649c80 x4 : ffff00007e649c80 [ 4.222487] x3 : ffff80001119b588 x2 : ffff8000108d1718 [ 4.227940] x1 : ffff800011bd5000 x0 : ffff00007ac21600 [ 4.233391] Call trace: [ 4.235906] rtw_load_firmware_cb+0x54/0xbc [ 4.240198] request_firmware_work_func+0x44/0xb4 [ 4.245027] process_one_work+0x178/0x1e4 [ 4.249142] worker_thread+0x1d0/0x268 [ 4.252989] kthread+0xe8/0xf8 [ 4.256127] ret_from_fork+0x10/0x18 [ 4.259800] Code: f94013f5 a8c37bfd d65f03c0 f9000260 (f9401681) [ 4.266049] ---[ end trace f822ebae1a8545c2 ]--- To avoid this, wait on the completion callbacks in rtw_core_deinit() before releasing firmware and continuing teardown. Note that rtw_wait_firmware_completion() was introduced with c8e5695eae9959fc5774c0f490f2450be8bad3de ("rtw88: load wowlan firmware if wowlan is supported"), so backports to earlier branches may need to inline wait_for_completion(&rtwdev->fw.completion) instead. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200920132621.26468-2-afaerber@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath6kl: wmi: prevent a shift wrapping bug in ath6kl_wmi_delete_pstream_cmd()Dan Carpenter1-0/+5
[ Upstream commit 6a950755cec1a90ddaaff3e4acb5333617441c32 ] The "tsid" is a user controlled u8 which comes from debugfs. Values more than 15 are invalid because "active_tsids" is a 16 bit variable. If the value of "tsid" is more than 31 then that leads to a shift wrapping bug. Fixes: 8fffd9e5ec9e ("ath6kl: Implement support for QOS-enable and QOS-disable from userspace") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200918142732.GA909725@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: Add checked value for ath11k_ahb_removeBo YU1-3/+7
[ Upstream commit 80b892fc8a90e91498babf0f6817139e5ec64b5c ] Return value form wait_for_completion_timeout should to be checked. This is detected by Coverity: #CID:1464479 (CHECKED_RETURN) Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Bo YU <tsu.yubo@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200621095136.7xdbzkthoxuw2qow@debian.debian-2 Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: wilc1000: clean up resource in error path of init mon interfaceHuang Guobin1-2/+1
[ Upstream commit 55bd149978679742374c800e56e8f6bc74378bbe ] The wilc_wfi_init_mon_int() forgets to clean up resource when register_netdevice() failed. Add the missed call to fix it. And the return value of netdev_priv can't be NULL, so remove the unnecessary error handling. Fixes: 588713006ea4 ("staging: wilc1000: avoid the use of 'wilc_wfi_mon' static variable") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Huang Guobin <huangguobin4@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200917123019.206382-1-huangguobin4@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: fix uninitialized return in ath11k_spectral_process_data()Dan Carpenter1-0/+2
[ Upstream commit c7187acc3cd08a17e7b506b2b5277f42d1504d29 ] There is a success path where "ret" isn't initialized where we never have a ATH11K_SPECTRAL_TAG_SCAN_SEARCH and then ret isn't initialized. Fixes: 9d11b7bff950 ("ath11k: add support for spectral scan") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200619142922.GA267142@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: fix a double free and a memory leakTom Rix1-1/+3
[ Upstream commit 7e8453e35e406981d7c529ff8f804285bc894ba3 ] clang static analyzer reports this problem mac.c:6204:2: warning: Attempt to free released memory kfree(ar->mac.sbands[NL80211_BAND_2GHZ].channels); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The channels pointer is allocated in ath11k_mac_setup_channels_rates() When it fails midway, it cleans up the memory it has already allocated. So the error handling needs to skip freeing the memory. There is a second problem. ath11k_mac_setup_channels_rates(), allocates 3 channels. err_free misses releasing ar->mac.sbands[NL80211_BAND_6GHZ].channels Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200906212625.17059-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: don't treat NULL pointer as an arrayBrian Norris1-2/+3
[ Upstream commit 22b726cbdd09d9891ede8aa122a950d2d0ae5e09 ] I'm not a standards expert, but this really looks to be undefined behavior, when chip->dig_cck may be NULL. (And, we're trying to do a NULL check a few lines down, because some chip variants will use NULL.) Fixes: fc637a860a82 ("rtw88: 8723d: Set IG register for CCK rate") Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200821211716.1631556-1-briannorris@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29wilc1000: Fix memleak in wilc_bus_probeDinghao Liu1-2/+3
[ Upstream commit 9a19a939abfa7d949f584a7ad872e683473fdc14 ] When devm_clk_get() returns -EPROBE_DEFER, spi_priv should be freed just like when wilc_cfg80211_init() fails. Fixes: 854d66df74aed ("staging: wilc1000: look for rtc_clk clock in spi mode") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Acked-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200820055256.24333-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29wilc1000: Fix memleak in wilc_sdio_probeDinghao Liu1-2/+3
[ Upstream commit 8d95ab34b21ee0f870a9185b6457e8f6eb54914c ] When devm_clk_get() returns -EPROBE_DEFER, sdio_priv should be freed just like when wilc_cfg80211_init() fails. Fixes: 8692b047e86cf ("staging: wilc1000: look for rtc_clk clock") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Acked-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200820054819.23365-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: Do not use GFP_KERNEL in atomic contextChristophe JAILLET1-1/+1
[ Upstream commit d2ab7f00f4321370a8ee14e5630d4349fdacc42e ] A possible call chain is as follow: mwifiex_sdio_interrupt (sdio.c) --> mwifiex_main_process (main.c) --> mwifiex_process_cmdresp (cmdevt.c) --> mwifiex_process_sta_cmdresp (sta_cmdresp.c) --> mwifiex_ret_802_11_scan (scan.c) --> mwifiex_parse_single_response_buf (scan.c) 'mwifiex_sdio_interrupt()' is an interrupt function. Also note that 'mwifiex_ret_802_11_scan()' already uses GFP_ATOMIC. So use GFP_ATOMIC instead of GFP_KERNEL when memory is allocated in 'mwifiex_parse_single_response_buf()'. Fixes: 7c6fa2a843c5 ("mwifiex: use cfg80211 dynamic scan table and cfg80211_get_bss API") or Fixes: 601216e12c65e ("mwifiex: process RX packets in SDIO IRQ thread directly") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200809092906.744621-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcmfmac: check ndev pointerTom Rix1-1/+1
[ Upstream commit 9c9f015bc9f8839831c7ba0a6d731a3853c464e2 ] Clang static analysis reports this error brcmfmac/core.c:490:4: warning: Dereference of null pointer (*ifp)->ndev->stats.rx_errors++; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this block of code if (ret || !(*ifp) || !(*ifp)->ndev) { if (ret != -ENODATA && *ifp) (*ifp)->ndev->stats.rx_errors++; brcmu_pkt_buf_free_skb(skb); return -ENODATA; } (*ifp)->ndev being NULL is caught as an error But then it is used to report the error. So add a check before using it. Fixes: 91b632803ee4 ("brcmfmac: Use net_device_stats from struct net_device") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802161804.6126-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: Fix possible memleak in ath11k_qmi_init_serviceWang Yufen1-0/+1
[ Upstream commit 28f1632118818d9dccabf4c0fccfe49686742317 ] When qmi_add_lookup fail, we should destroy the workqueue Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1595237804-66297-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29wcn36xx: Fix reported 802.11n rx_highest rate wcn3660/wcn3680Bryan O'Donoghue1-1/+1
[ Upstream commit 3b9fb6791e7113679b1eb472e6ce1659e80f5797 ] Qualcomm's document "80-WL007-1 Rev. J" states that the highest rx rate for the WCN3660 and WCN3680 on MCS 7 is 150 Mbps not the 72 Mbps stated here. This patch fixes the data-rate declared in the 5GHz table. 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/20200802004824.1307124-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath10k: Fix the size used in a 'dma_free_coherent()' call in an error ↵Christophe JAILLET1-1/+1
handling path [ Upstream commit 454530a9950b5a26d4998908249564cedfc4babc ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'. Fixes: 1863008369ae ("ath10k: fix shadow register implementation for WCN3990") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802122227.678637-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath9k: Fix potential out of bounds in ath9k_htc_txcompletion_cb()Dan Carpenter1-0/+2
[ Upstream commit 2705cd7558e718a7240c64eb0afb2edad5f8c190 ] The value of "htc_hdr->endpoint_id" comes from skb->data so Smatch marks it as untrusted so we have to check it before using it as an array offset. This is similar to a bug that syzkaller found in commit e4ff08a4d727 ("ath9k: Fix use-after-free Write in ath9k_htc_rx_msg") so it is probably a real issue. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200813141253.GA457408@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath6kl: prevent potential array overflow in ath6kl_add_new_sta()Dan Carpenter1-0/+3
[ Upstream commit 54f9ab7b870934b70e5a21786d951fbcf663970f ] The value for "aid" comes from skb->data so Smatch marks it as untrusted. If it's invalid then it can result in an out of bounds array access in ath6kl_add_new_sta(). Fixes: 572e27c00c9d ("ath6kl: Fix AP mode connect event parsing and TIM updates") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200813141315.GB457408@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-22 21:39:44 +0300