summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel
AgeCommit message (Collapse)AuthorFilesLines
14 dayswifi: iwlegacy: Check rate_idx range after additionStanislaw Gruszka1-1/+4
[ Upstream commit 0de19d5ae0b2c5b18b88c5c7f0442f707a207409 ] Limit rate_idx to IL_LAST_OFDM_RATE for 5GHz band for thinkable case the index is incorrect. Reported-by: Fedor Pchelkin <pchelkin@ispras.ru> Reported-by: Alexei Safin <a.safin@rosa.ru> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Reviewed-by: Fedor Pchelkin <pchelkin@ispras.ru> Link: https://patch.msgid.link/20250525144524.GA172583@wp.pl Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
14 dayswifi: iwlwifi: fw: Fix possible memory leak in iwl_fw_dbg_collectPagadala Yesu Anjaneyulu1-1/+6
[ Upstream commit cc8d9cbf269dab363c768bfa9312265bc807fca5 ] Ensure descriptor is freed on error to avoid memory leak. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250611222325.8158d15ec866.Ifa3e422c302397111f20a16da7509e6574bc19e3@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
14 dayswifi: iwlwifi: dvm: fix potential overflow in rs_fill_link_cmd()Rand Deeb1-1/+1
[ Upstream commit e3ad987e9dc7d1e12e3f2f1e623f0e174cd0ca78 ] The 'index' variable in the rs_fill_link_cmd() function can reach LINK_QUAL_MAX_RETRY_NUM during the execution of the inner loop. This variable is used as an index for the lq_cmd->rs_table array, which has a size of LINK_QUAL_MAX_RETRY_NUM, without proper validation. Modify the condition of the inner loop to ensure that the 'index' variable does not exceed LINK_QUAL_MAX_RETRY_NUM - 1, thereby preventing any potential overflow issues. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb <rand.sec96@gmail.com> Link: https://patch.msgid.link/20240313101755.269209-1-rand.sec96@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
14 dayswifi: iwlwifi: mvm: fix scan request validationAvraham Stern1-1/+1
[ Upstream commit 7c2f3ec7707188d8d5269ae2dce97d7be3e9f261 ] The scan request validation function uses bitwise and instead of logical and. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.3fbc1f27871b.I7a8ee91f463c1a2d9d8561c8232e196885d02c43@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
14 daysiwlwifi: Add missing check for alloc_ordered_workqueueJiasheng Jiang1-2/+9
[ Upstream commit 90a0d9f339960448a3acc1437a46730f975efd6a ] Add check for the return value of alloc_ordered_workqueue since it may return NULL pointer. Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://patch.msgid.link/20230110014848.28226-1-jiasheng@iscas.ac.cn Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
14 dayswifi: iwlwifi: Fix memory leak in iwl_mvm_init()Xiu Jianfeng1-1/+3
[ Upstream commit ed2e916c890944633d6826dce267579334f63ea5 ] When iwl_opmode_register() fails, it does not unregster rate control, which will cause a memory leak issue, this patch fixes it. Fixes: 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://patch.msgid.link/20221109035213.570-1-xiujianfeng@huawei.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10wifi: iwlwifi: fw: allocate chained SG tables for dumpJohannes Berg1-28/+58
[ Upstream commit 7774e3920029398ad49dc848b23840593f14d515 ] The firmware dumps can be pretty big, and since we use single pages for each SG table entry, even the table itself may end up being an order-5 allocation. Build chained tables so that we need not allocate a higher-order table here. This could be improved and cleaned up, e.g. by using the SG pool code or simply kvmalloc(), but all of that would require also updating the devcoredump first since that frees it all, so we need to be more careful. SG pool might also run against the CONFIG_ARCH_NO_SG_CHAIN limitation, which is irrelevant here. Also use _devcd_free_sgtable() for the error paths now, much simpler especially since it's in two places now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250209143303.697c7a465ac9.Iea982df46b5c075bfb77ade36f187d99a70c63db@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13wifi: iwlwifi: limit printed string from FW fileJohannes Berg1-1/+1
[ Upstream commit e0dc2c1bef722cbf16ae557690861e5f91208129 ] There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer. Fix that by limiting the print format to the size of the buffer we have. Fixes: aee1b6385e29 ("iwlwifi: support fseq tlv and print fseq version") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250209143303.cb5f9d0c2f5d.Idec695d53c6c2234aade306f7647b576c7e3d928@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13wifi: iwlwifi: avoid memory leakMiri Korenblit1-5/+8
[ Upstream commit 80e96206a3ef348fbd658d98f2f43149c36df8bc ] A caller of iwl_acpi_get_dsm_object must free the returned object. iwl_acpi_get_dsm_integer returns immediately without freeing it if the expected size is more than 8 bytes. Fix that. Note that with the current code this will never happen, since the caller of iwl_acpi_get_dsm_integer already checks that the expected size if either 1 or 4 bytes, so it can't exceed 8 bytes. While at it, print the DSM value instead of the return value, as this was the intention in the first place. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241228223206.bf61eaab99f8.Ibdc5df02f885208c222456d42c889c43b7e3b2f7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-01wifi: iwlwifi: add a few rate index validity checksAnjaneyulu2-5/+11
commit efbe8f81952fe469d38655744627d860879dcde8 upstream. Validate index before access iwl_rate_mcs to keep rate->index inside the valid boundaries. Use MCS_0_INDEX if index is less than MCS_0_INDEX and MCS_9_INDEX if index is greater then MCS_9_INDEX. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230614123447.79f16b3aef32.If1137f894775d6d07b78cbf3a6163ffce6399507@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-14wifi: ipw2x00: libipw_rx_any(): fix bad alignmentJiapeng Chong1-4/+4
[ Upstream commit 4fa4f049dc0d9741b16c96bcbf0108c85368a2b9 ] This patch fixes incorrect code alignment. ./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:871:2-3: code aligned with following code on line 882. ./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:886:2-3: code aligned with following code on line 900. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=11381 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241101060725.54640-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14wifi: iwlwifi: mvm: Use the sync timepoint API in suspendDaniel Gabay2-1/+5
[ Upstream commit 9715246ca0bfc9feaec1b4ff5b3d38de65a7025d ] When starting the suspend flow, HOST_D3_START triggers an _async_ firmware dump collection for debugging purposes. The async worker may race with suspend flow and fail to get NIC access, resulting in the following warning: "Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)" Fix this by switching to the sync version to ensure the dump completes before proceeding with the suspend flow, avoiding potential race issues. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241010140328.9aae318cd593.I4b322009f39489c0b1d8893495c887870f73ed9c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08wifi: iwlwifi: mvm: fix 6 GHz scan constructionJohannes Berg1-1/+2
commit 7245012f0f496162dd95d888ed2ceb5a35170f1a upstream. If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32. Cc: stable@vger.kernel.org Fixes: eae94cf82d74 ("iwlwifi: mvm: add support for 6GHz") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219375 Link: https://patch.msgid.link/20241023091744.f4baed5c08a1.I8b417148bbc8c5d11c101e1b8f5bf372e17bf2a7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-08wifi: iwlegacy: Clear stale interrupts before resuming deviceVille Syrjälä1-0/+2
commit 07c90acb071b9954e1fecb1e4f4f13d12c544b34 upstream. iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 00 c6 83 ad 05 00 00 00 48 89 df e8 98 1b fc ff 85 c0 41 89 c7 0f 84 e9 02 00 00 48 c7 c7 a0 e6 48 a0 e8 d1 77 c4 e0 <0f> 0b eb 2d 84 c0 0f 85 8b 01 00 00 c6 87 ad 05 00 00 00 e8 69 1b [ 16.132504] RSP: 0018:ffffc9000029fcf0 EFLAGS: 00010282 [ 16.132507] RAX: 0000000000000000 RBX: ffff8880072008e0 RCX: 0000000000000001 [ 16.132509] RDX: ffffffff81f21a18 RSI: 0000000000000086 RDI: 0000000000000001 [ 16.132510] RBP: ffff8880072003c0 R08: 0000000000000000 R09: 0000000000000003 [ 16.132512] R10: 0000000000000000 R11: ffff88807e5b0000 R12: 0000000000000001 [ 16.132514] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000ffffff92 [ 16.132515] FS: 0000000000000000(0000) GS:ffff88807c200000(0000) knlGS:0000000000000000 [ 16.132517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.132519] CR2: 000055dd43786c08 CR3: 000000000978f000 CR4: 00000000000006f0 [ 16.132521] Call Trace: [ 16.132525] <TASK> [ 16.132526] ? __warn+0x77/0x120 [ 16.132532] ? ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132564] ? report_bug+0x15c/0x190 [ 16.132568] ? handle_bug+0x36/0x70 [ 16.132571] ? exc_invalid_op+0x13/0x60 [ 16.132573] ? asm_exc_invalid_op+0x16/0x20 [ 16.132579] ? ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132611] ? snd_hdac_bus_init_cmd_io+0x24/0x200 [snd_hda_core] [ 16.132617] ? pick_eevdf+0x133/0x1c0 [ 16.132622] ? check_preempt_wakeup_fair+0x70/0x90 [ 16.132626] ? wakeup_preempt+0x4a/0x60 [ 16.132628] ? ttwu_do_activate.isra.0+0x5a/0x190 [ 16.132632] wiphy_resume+0x79/0x1a0 [cfg80211] [ 16.132675] ? wiphy_suspend+0x2a0/0x2a0 [cfg80211] [ 16.132697] dpm_run_callback+0x75/0x1b0 [ 16.132703] device_resume+0x97/0x200 [ 16.132707] async_resume+0x14/0x20 [ 16.132711] async_run_entry_fn+0x1b/0xa0 [ 16.132714] process_one_work+0x13d/0x350 [ 16.132718] worker_thread+0x2be/0x3d0 [ 16.132722] ? cancel_delayed_work_sync+0x70/0x70 [ 16.132725] kthread+0xc0/0xf0 [ 16.132729] ? kthread_park+0x80/0x80 [ 16.132732] ret_from_fork+0x28/0x40 [ 16.132735] ? kthread_park+0x80/0x80 [ 16.132738] ret_from_fork_asm+0x11/0x20 [ 16.132741] </TASK> [ 16.132742] ---[ end trace 0000000000000000 ]--- [ 16.132930] ------------[ cut here ]------------ [ 16.132932] WARNING: CPU: 0 PID: 181 at net/mac80211/driver-ops.c:41 drv_stop+0xe7/0xf0 [mac80211] [ 16.132957] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.133014] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Tainted: G W 6.11.0-cl+ #143 [ 16.133018] Tainted: [W]=WARN [ 16.133019] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.133021] Workqueue: async async_run_entry_fn [ 16.133025] RIP: 0010:drv_stop+0xe7/0xf0 [mac80211] [ 16.133048] Code: 48 85 c0 74 0e 48 8b 78 08 89 ea 48 89 de e8 e0 87 04 00 65 ff 0d d1 de c4 5f 0f 85 42 ff ff ff e8 be 52 c2 e0 e9 38 ff ff ff <0f> 0b 5b 5d c3 0f 1f 40 00 41 54 49 89 fc 55 53 48 89 f3 2e 2e 2e [ 16.133050] RSP: 0018:ffffc9000029fc50 EFLAGS: 00010246 [ 16.133053] RAX: 0000000000000000 RBX: ffff8880072008e0 RCX: ffff88800377f6c0 [ 16.133054] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8880072008e0 [ 16.133056] RBP: 0000000000000000 R08: ffffffff81f238d8 R09: 0000000000000000 [ 16.133058] R10: ffff8880080520f0 R11: 0000000000000000 R12: ffff888008051c60 [ 16.133060] R13: ffff8880072008e0 R14: 0000000000000000 R15: ffff8880072011d8 [ 16.133061] FS: 0000000000000000(0000) GS:ffff88807c200000(0000) knlGS:0000000000000000 [ 16.133063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.133065] CR2: 000055dd43786c08 CR3: 000000000978f000 CR4: 00000000000006f0 [ 16.133067] Call Trace: [ 16.133069] <TASK> [ 16.133070] ? __warn+0x77/0x120 [ 16.133075] ? drv_stop+0xe7/0xf0 [mac80211] [ 16.133098] ? report_bug+0x15c/0x190 [ 16.133100] ? handle_bug+0x36/0x70 [ 16.133103] ? exc_invalid_op+0x13/0x60 [ 16.133105] ? asm_exc_invalid_op+0x16/0x20 [ 16.133109] ? drv_stop+0xe7/0xf0 [mac80211] [ 16.133132] ieee80211_do_stop+0x55a/0x810 [mac80211] [ 16.133161] ? fq_codel_reset+0xa5/0xc0 [sch_fq_codel] [ 16.133164] ieee80211_stop+0x4f/0x180 [mac80211] [ 16.133192] __dev_close_many+0xa2/0x120 [ 16.133195] dev_close_many+0x90/0x150 [ 16.133198] dev_close+0x5d/0x80 [ 16.133200] cfg80211_shutdown_all_interfaces+0x40/0xe0 [cfg80211] [ 16.133223] wiphy_resume+0xb2/0x1a0 [cfg80211] [ 16.133247] ? wiphy_suspend+0x2a0/0x2a0 [cfg80211] [ 16.133269] dpm_run_callback+0x75/0x1b0 [ 16.133273] device_resume+0x97/0x200 [ 16.133277] async_resume+0x14/0x20 [ 16.133280] async_run_entry_fn+0x1b/0xa0 [ 16.133283] process_one_work+0x13d/0x350 [ 16.133287] worker_thread+0x2be/0x3d0 [ 16.133290] ? cancel_delayed_work_sync+0x70/0x70 [ 16.133294] kthread+0xc0/0xf0 [ 16.133296] ? kthread_park+0x80/0x80 [ 16.133299] ret_from_fork+0x28/0x40 [ 16.133302] ? kthread_park+0x80/0x80 [ 16.133304] ret_from_fork_asm+0x11/0x20 [ 16.133307] </TASK> [ 16.133308] ---[ end trace 0000000000000000 ]--- [ 16.133335] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume [cfg80211] returns -110 [ 16.133360] ieee80211 phy0: PM: failed to restore async: error -110 Cc: stable@vger.kernel.org Cc: Stanislaw Gruszka <stf_xl@wp.pl> Cc: Kalle Valo <kvalo@kernel.org> Cc: linux-wireless@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241001200745.8276-1-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-08wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()Daniel Gabay1-6/+4
[ Upstream commit 07a6e3b78a65f4b2796a8d0d4adb1a15a81edead ] 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer. Fixes: f130bb75d881 ("iwlwifi: add FW recovery flow") Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241010140328.76c73185951e.Id3b6ca82ced2081f5ee4f33c997491d0ebda83f7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08wifi: iwlwifi: mvm: disconnect station vifs if recovery failedEmmanuel Grumbach1-1/+13
[ Upstream commit e50a88e5cb8792cc416866496288c5f4d1eb4b1f ] This will allow to reconnect immediately instead of leaving the connection in a limbo state. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240128084842.e90531cd3a36.Iebdc9483983c0d8497f9dcf9d79ec37332a5fdcc@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Stable-dep-of: 07a6e3b78a65 ("wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: iwlwifi: mvm: increase the time between ranging measurementsAvraham Stern1-1/+1
[ Upstream commit 3a7ee94559dfd640604d0265739e86dec73b64e8 ] The algo running in fw may take a little longer than 5 milliseconds, (e.g. measurement on 80MHz while associated). Increase the minimum time between measurements to 7 milliseconds. Fixes: 830aa3e7d1ca ("iwlwifi: mvm: add support for range request command version 13") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240729201718.d3f3c26e00d9.I09e951290e8a3d73f147b88166fd9a678d1d69ed@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: iwlwifi: clear trans->state earlier upon errorEmmanuel Grumbach2-2/+2
[ Upstream commit 094513f8a2fbddee51b055d8035f995551f98fce ] When the firmware crashes, we first told the op_mode and only then, changed the transport's state. This is a problem if the op_mode's nic_error() handler needs to send a host command: it'll see that the transport's state still reflects that the firmware is alive. Today, this has no consequences since we set the STATUS_FW_ERROR bit and that will prevent sending host commands. iwl_fw_dbg_stop_restart_recording looks at this bit to know not to send a host command for example. To fix the hibernation, we needed to reset the firmware without having an error and checking STATUS_FW_ERROR to see whether the firmware is alive will no longer hold, so this change is necessary as well. Change the flow a bit. Change trans->state before calling the op_mode's nic_error() method and check trans->state instead of STATUS_FW_ERROR. This will keep the current behavior of iwl_fw_dbg_stop_restart_recording upon firmware error, and it'll allow us to call iwl_fw_dbg_stop_restart_recording safely even if STATUS_FW_ERROR is clear, but yet, the firmware is not alive. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.9d7427fbdfd7.Ia056ca57029a382c921d6f7b6a6b28fc480f2f22@changeid [I missed this was a dependency for the hibernation fix, changed the commit message a bit accordingly] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: iwlwifi: mvm: don't wait for tx queues if firmware is deadEmmanuel Grumbach1-1/+8
[ Upstream commit 3a84454f5204718ca5b4ad2c1f0bf2031e2403d1 ] There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead. Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.a7cbd794cee9.I44a739fbd4ffcc46b83844dd1c7b2eb0c7b270f6@changeid [edit commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedEmmanuel Grumbach1-0/+2
[ Upstream commit 0668ebc8c2282ca1e7eb96092a347baefffb5fe7 ] Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.5abe71ca1b6b.I97a968cb8be1f24f94652d9b110ecbf6af73f89e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: iwlwifi: mvm: fix iwl_mvm_scan_fits() calculationDaniel Gabay1-11/+12
[ Upstream commit d44162280899c3fc2c6700e21e491e71c3c96e3d ] The calculation should consider also the 6GHz IE's len, fix that. In addition, in iwl_mvm_sched_scan_start() the scan_fits helper is called only in case non_psc_incldued is true, but it should be called regardless, fix that as well. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.7db825442fd2.I99f4d6587709de02072fd57957ec7472331c6b1d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: iwlwifi: lower message level for FW buffer destinationBenjamin Berg1-1/+2
[ Upstream commit f8a129c1e10256c785164ed5efa5d17d45fbd81b ] An invalid buffer destination is not a problem for the driver and it does not make sense to report it with the KERN_ERR message level. As such, change the message to use IWL_DEBUG_FW. Reported-by: Len Brown <lenb@kernel.org> Closes: https://lore.kernel.org/r/CAJvTdKkcxJss=DM2sxgv_MR5BeZ4_OC-3ad6tA40TYH2yqHCWw@mail.gmail.com Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.20abf78f05bc.Ifbcecc2ae9fb40b9698302507dcba8b922c8d856@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-12wifi: iwlwifi: remove fw_running opShahar S Matityahu3-9/+1
[ Upstream commit 37733bffda3285d18bd1d72c14b3a1cf39c56a5e ] fw_running assumes that memory can be retrieved only after alive. This assumption is no longer true as we support dump before alive. To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED bit in trans status is set before dumping instead of the prior check. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-04wifi: iwlwifi: fw: Fix debugfs command sendingMukesh Sisodiya1-1/+5
[ Upstream commit 048449fc666d736a1a17d950fde0b5c5c8fd10cc ] During debugfs command handling transport function is used directly, this bypasses the locking used by runtime operation function and leads to a kernel warning when two commands are sent in parallel. Fix it by using runtime operations function when sending debugfs command. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231004123422.4f80ac90658a.Ia1dfa1195c919f3002fe08db3eefbd2bfa921bbf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-04wifi: iwlwifi: abort scan when rfkill on but device enabledMiri Korenblit1-1/+1
[ Upstream commit 3c6a0b1f0add72e7f522bc9145222b86d0a7712a ] In RFKILL we first set the RFKILL bit, then we abort scan (if one exists) by waiting for the notification from FW and notifying mac80211. And then we stop the device. But in case we have a scan ongoing in the period of time between rfkill on and before the device is stopped - we will not wait for the FW notification because of the iwl_mvm_is_radio_killed() condition, and then the scan_status and uid_status are misconfigured, (scan_status is cleared but uid_status not) and when the notification suddenly arrives (before stopping the device) we will get into the assert about scan_status and uid_status mismatch. Fix this by waiting for FW notif when rfkill is on but the device isn't disabled yet. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231004123422.c43b69aa2c77.Icc7b5efb47974d6f499156ff7510b786e177993b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-27wifi: iwlwifi: mvm: properly set 6 GHz channel direct probe optionAyala Beker1-1/+4
[ Upstream commit 989830d1cf16bd149bf0690d889a9caef95fb5b1 ] Ensure that the 6 GHz channel is configured with a valid direct BSSID, avoiding any invalid or multicast BSSID addresses. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240513132416.91a631a0fe60.I2ea2616af9b8a2eaf959b156c69cf65a2f1204d4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-27wifi: iwlwifi: mvm: Handle BIGTK cipher in kek_kck cmdYedidya Benshimol1-2/+11
[ Upstream commit 08b16d1b5997dc378533318e2a9cd73c7a898284 ] The BIGTK cipher field was added to the kek_kck_material_cmd but wasn't assigned. Fix that by differentiating between the IGTK/BIGTK keys and assign the ciphers fields accordingly. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240513132416.7fd0b22b7267.Ie9b581652b74bd7806980364d59e1b2e78e682c0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-27wifi: iwlwifi: mvm: d3: fix WoWLAN command version lookupYedidya Benshimol1-1/+2
[ Upstream commit b7ffca99313d856f7d1cc89038d9061b128e8e97 ] After moving from commands to notificaitons in the d3 resume flow, removing the WOWLAN_GET_STATUSES and REPLY_OFFLOADS_QUERY_CMD causes the return of the default value when looking up their version. Returning zero here results in the driver sending the not supported NON_QOS_TX_COUNTER_CMD. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240510170500.8cabfd580614.If3a0db9851f56041f8f5360959354abd5379224a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05wifi: iwlwifi: mvm: don't read past the mfuart notifcationEmmanuel Grumbach1-10/+0
[ Upstream commit 4bb95f4535489ed830cf9b34b0a891e384d1aee4 ] In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing. This was reported by KFENCE. Fixes: bdccdb854f2f ("iwlwifi: mvm: support MFUART dump in case of MFUART assert") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240513132416.ba82a01a559e.Ia91dd20f5e1ca1ad380b95e68aebf2794f553d9b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsMiri Korenblit1-2/+2
[ Upstream commit 60d62757df30b74bf397a2847a6db7385c6ee281 ] In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first. Fixes: c1a7515393e4 ("iwlwifi: mvm: add adaptive dwell support") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://msgid.link/20240513132416.6e4d1762bf0d.I5a0e6cc8f02050a766db704d15594c61fe583d45@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05wifi: iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdefShahar S Matityahu1-1/+1
[ Upstream commit 87821b67dea87addbc4ab093ba752753b002176a ] The driver should call iwl_dbg_tlv_free even if debugfs is not defined since ini mode does not depend on debugfs ifdef. Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external file") Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240510170500.c8e3723f55b0.I5e805732b0be31ee6b83c642ec652a34e974ff10@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05wifi: iwlwifi: mvm: revert gen2 TX A-MPDU size to 64Johannes Berg1-7/+2
[ Upstream commit 4a7aace2899711592327463c1a29ffee44fcc66e ] We don't actually support >64 even for HE devices, so revert back to 64. This fixes an issue where the session is refused because the queue is configured differently from the actual session later. Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Liad Kaufman <liad.kaufman@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240510170500.52f7b4cf83aa.If47e43adddf7fe250ed7f5571fbb35d8221c7c47@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-02wifi: iwlwifi: mvm: return uid from iwl_mvm_build_scan_cmdMiri Korenblit1-1/+2
[ Upstream commit bada85a3f584763deadd201147778c3e791d279c ] This function is supposed to return a uid on success, and an errno in failure. But it currently returns the return value of the specific cmd version handler, which in turn returns 0 on success and errno otherwise. This means that on success, iwl_mvm_build_scan_cmd will return 0 regardless if the actual uid. Fix this by returning the uid if the handler succeeded. Fixes: 687db6ff5b70 ("iwlwifi: scan: make new scan req versioning flow") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://msgid.link/20240415114847.5e2d602b3190.I4c4931021be74a67a869384c8f8ee7463e0c7857@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-02wifi: iwlwifi: mvm: remove old PASN station when adding a new oneAvraham Stern1-0/+2
[ Upstream commit dbfff5bf9292714f02ace002fea8ce6599ea1145 ] If a PASN station is added, and an old PASN station already exists for the same mac address, remove the old station before adding the new one. Keeping the old station caueses old security context to be used in measurements. Fixes: 0739a7d70e00 ("iwlwifi: mvm: initiator: add option for adding a PASN responder") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240415114847.ef3544a416f2.I4e8c7c8ca22737f4f908ae5cd4fc0b920c703dd3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-10wifi: iwlwifi: mvm: rfi: fix potential response leaksJohannes Berg1-2/+6
[ Upstream commit 06a093807eb7b5c5b29b6cff49f8174a4e702341 ] If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that. Fixes: 21254908cbe9 ("iwlwifi: mvm: add RFI-M support") Co-authored-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240319100755.db2fa0196aa7.I116293b132502ac68a65527330fa37799694b79c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-10iwlwifi: mvm: rfi: use kmemdup() to replace kzalloc + memcpyBixuan Cui1-3/+1
[ Upstream commit 08186e2501eec554cde8bae53b1d1de4d54abdf4 ] Fix memdup.cocci warning: ./drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:110:8-15: WARNING opportunity for kmemdup Signed-off-by: Bixuan Cui <cuibixuan@linux.alibaba.com> Link: https://lore.kernel.org/r/1635317920-84725-1-git-send-email-cuibixuan@linux.alibaba.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Stable-dep-of: 06a093807eb7 ("wifi: iwlwifi: mvm: rfi: fix potential response leaks") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27wireless: Remove redundant 'flush_workqueue()' callsChristophe JAILLET3-3/+0
[ Upstream commit ff1cc2fa3055ee4c83839f38b74b4ee370a2291c ] 'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/0855d51423578ad019c0264dad3fe47a2e8af9c7.1633849511.git.christophe.jaillet@wanadoo.fr Stable-dep-of: cb5942b77c05 ("wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27wifi: iwlwifi: mvm: don't set replay counters to 0xffJohannes Berg1-3/+1
[ Upstream commit d5bd4041cd70faf26fc9a54bd6f172537bbe77f3 ] The firmware (later) actually uses the values even for keys that are invalid as far as the host is concerned, later in rekeying, and then only sets the low 48 bits since the PNs are only 48 bits over the air. It does, however, compare the full 64 bits later, obviously causing problems. Remove the memset and use kzalloc instead to avoid any old heap data leaking to the firmware. We already init all the other fields in the struct anyway. This leaves the data set to zero for any unused fields, so the firmware can look at them safely even if they're not used right now. Fixes: 79e561f0f05a ("iwlwifi: mvm: d3: implement RSC command version 5") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206175739.462101146fef.I10f3855b99417af4247cff04af78dcbc6cb75c9c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27wifi: iwlwifi: fix EWRD table validity checkMiri Korenblit1-1/+1
[ Upstream commit c8d8f3911135921ace8e939ea0956b55f74bf8a0 ] EWRD ACPI table contains up to 3 additional sar profiles. According to the BIOS spec, the table contains a n_profile variable indicating how many additional profiles exist in the table. Currently we check that n_profiles is not <= 0. But according to the BIOS spec, 0 is a valid value, and it can't be < 0 anyway because we receive that from ACPI as an unsigned integer. Fixes: 39c1a9728f93 ("iwlwifi: refactor the SAR tables from mvm to acpi") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240129211905.448ea2f40814.Iffd2aadf8e8693e6cb599bee0406a800a0c1e081@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27wifi: iwlwifi: dbg-tlv: ensure NUL terminationJohannes Berg1-0/+6
[ Upstream commit ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea ] The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it. Fixes: a9248de42464 ("iwlwifi: dbg_ini: add TLV allocation new API support") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240128084842.be15e858ee89.Ibff93429cf999eafc7b26f3eef4c055dc84984a0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27wifi: iwlwifi: mvm: report beacon protection failuresJohannes Berg1-11/+15
[ Upstream commit 91380f768d7f6e3d003755defa792e9a00a1444a ] Andrei reports that we just silently drop beacons after we report the key counters, but never report to userspace, so wpa_supplicant cannot send the WNM action frame. Fix that. Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available") Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240128084842.7d855442cdce.Iba90b26f893dc8c49bfb8be65373cd0a138af12c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-01wifi: iwlwifi: mvm: avoid baid size integer overflowJohannes Berg1-1/+1
[ Upstream commit 1a528ab1da324d078ec60283c34c17848580df24 ] Roee reported various hard-to-debug crashes with pings in EHT aggregation scenarios. Enabling KASAN showed that we access the BAID allocation out of bounds, and looking at the code a bit shows that since the reorder buffer entry (struct iwl_mvm_reorder_buf_entry) is 128 bytes if debug such as lockdep is enabled, then staring from an agg size 512 we overflow the size calculation, and allocate a much smaller structure than we should, causing slab corruption once we initialize this. Fix this by simply using u32 instead of u16. Reported-by: Roee Goldfiner <roee.h.goldfiner@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230620125813.f428c856030d.I2c2bb808e945adb71bc15f5b2bac2d8957ea90eb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23wifi: iwlwifi: Fix some error codesDan Carpenter1-6/+6
[ Upstream commit c6ebb5b67641994de8bc486b33457fe0b681d6fe ] This saves the error as PTR_ERR(wifi_pkg). The problem is that "wifi_pkg" is a valid pointer, not an error pointer. Set the error code to -EINVAL instead. Fixes: 2a8084147bff ("iwlwifi: acpi: support reading and storing WRDS revision 1 and 2") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://msgid.link/9620bb77-2d7c-4d76-b255-ad824ebf8e35@moroto.mountain Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23wifi: iwlwifi: fix a memory corruptionEmmanuel Grumbach1-1/+1
commit cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d upstream. iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer. Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218233 Fixes: cf29c5b66b9f ("iwlwifi: dbg_ini: implement time point handling") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240111150610.2d2b8b870194.I14ed76505a5cf87304e0c9cc05cc0ae85ed3bf91@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-26wifi: iwlwifi: mvm: send TX path flush in rfkillJohannes Berg1-1/+1
[ Upstream commit 2afc3dad39ea84a072d04ff40a417234326adc47 ] If we want to drop packets, that's surely a good thing to do when we want to enter rfkill. Send this command despite rfkill so we can successfully clean up everything, we need to handle it separately since it has CMD_WANT_SKB, so it's not going to automatically return success when in rfkill. Fixes: d4e3a341b87b ("iwlwifi: mvm: add support for new flush queue response") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231219215605.c528a6fa6cec.Ibe5e9560359ccc0fba60c35e01de285c376748a2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26wifi: iwlwifi: mvm: set siso/mimo chains to 1 in FW SMPS requestJohannes Berg1-11/+0
[ Upstream commit b1a2e5c310e063560760806d2cc5d2233c596067 ] The firmware changed their mind, don't set the chains to zero, instead set them to 1 as we normally would for connections to APs that don't use MIMO. Fixes: 2a7ce54ccc23 ("iwlwifi: mvm: honour firmware SMPS requests") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231219215605.7f031f1a127f.Idc816e0f604b07d22a9d5352bc23c445512fad14@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26wifi: iwlwifi: pcie: avoid a NULL pointer dereferenceAvraham Stern1-1/+1
[ Upstream commit ce038edfce43fb345f8dfdca0f7b17f535896701 ] It possible that while the rx rb is being handled, the transport has been stopped and re-started. In this case the tx queue pointer is not yet initialized, which will lead to a NULL pointer dereference. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231207044813.cd0898cafd89.I0b84daae753ba9612092bf383f5c6f761446e964@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-15wifi: iwlwifi: pcie: don't synchronize IRQs from IRQJohannes Berg3-14/+15
[ Upstream commit 400f6ebbc175286576c7f7fddf3c347d09d12310 ] On older devices (before unified image!) we can end up calling stop_device from an rfkill interrupt. However, in stop_device we attempt to synchronize IRQs, which then of course deadlocks. Avoid this by checking the context, if running from the IRQ thread then don't synchronize. This wouldn't be correct on a new device since RSS is supported, but older devices only have a single interrupt/queue. Fixes: 37fb29bd1f90 ("wifi: iwlwifi: pcie: synchronize IRQs before NAPI") Reviewed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231215111335.59aab00baed7.Iadfe154d6248e7f9dfd69522e5429dbbd72925d7@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-05wifi: iwlwifi: pcie: add another missing bh-disable for rxq->lockJohannes Berg1-2/+2
[ Upstream commit a4754182dc936b97ec7e9f6b08cdf7ed97ef9069 ] Evidently I had only looked at all the ones in rx.c, and missed this. Add bh-disable to this use of the rxq->lock as well. Fixes: 25edc8f259c7 ("iwlwifi: pcie: properly implement NAPI") Reported-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231208183100.e79ad3dae649.I8f19713c4383707f8be7fc20ff5cc1ecf12429bb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-28wifi: iwlwifi: Use FW rate for non-data framesMiri Korenblit1-5/+9
[ Upstream commit 499d02790495958506a64f37ceda7e97345a50a8 ] Currently we are setting the rate in the tx cmd for mgmt frames (e.g. during connection establishment). This was problematic when sending mgmt frames in eSR mode, as we don't know what link this frame will be sent on (This is decided by the FW), so we don't know what is the lowest rate. Fix this by not setting the rate in tx cmd and rely on FW to choose the right one. Set rate only for injected frames with fixed rate, or when no sta is given. Also set for important frames (EAPOL etc.) the High Priority flag. Fixes: 055b22e770dd ("iwlwifi: mvm: Set Tx rate and flags when there is not station") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.6c7e59620ee0.I6eaed3ccdd6dd62b9e664facc484081fc5275843@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-11 09:06:39 +0300