kernel/linux.git/drivers/net/wireless/intel, branch v6.19.12

wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()

2026-04-11T12:29:40+00:00

commit 744fabc338e87b95c4d1ff7c95bc8c0f834c6d99 upstream. The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Fixes: 5ac54afd4d97 ("wifi: iwlwifi: mvm: Add handling for scan offload match info notification") Signed-off-by: Alexey Velichayshiy Link: https://patch.msgid.link/20260207150335.1013646-1-a.velichayshiy@ispras.ru Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: mld: correctly set wifi generation data

2026-04-11T12:29:22+00:00

[ Upstream commit 687a95d204e72e52f2e6bc7a994cc82f76b2678f ] In each MAC context, the firmware expects the wifi generation data, i.e. whether or not HE/EHT (and in the future UHR) is enabled on that MAC. However, this is currently handled wrong in two ways: - EHT is only enabled when the interface is also an MLD, but we currently allow (despite the spec) connecting with EHT but without MLO. - when HE or EHT are used by TDLS peers, the firmware needs to have them enabled regardless of the AP Fix this by iterating setting up the data depending on the interface type: - for AP, just set it according to the BSS configuration - for monitor, set it according to HW capabilities - otherwise, particularly for client, iterate all stations and then their links on the interface in question and set according to their capabilities, this handles the AP and TDLS peers. Re-calculate this whenever a TDLS station is marked associated or removed so that it's kept updated, for the AP it's already updated on assoc/disassoc. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260319110722.404713b22177.Ic972b5e557d011a5438f8f97c1e793cc829e2ea9@changeid Link: https://patch.msgid.link/20260324093333.2953495-1-miriam.rachel.korenblit@intel.com Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: don't send a 6E related command when not supported

2026-04-11T12:29:22+00:00

[ Upstream commit 323156c3541e23da7e582008a7ac30cd51b60acd ] MCC_ALLOWED_AP_TYPE_CMD is related to 6E support. Do not send it if the device doesn't support 6E. Apparently, the firmware is mistakenly advertising support for this command even on AX201 which does not support 6E and then the firmware crashes. Fixes: 0d2fc8821a7d ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220804 Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260324113316.e171f0163f2a.I0c444d1f82d1773054e7ffc391ad49697d58f44e@changeid Signed-off-by: Sasha Levin

wifi: iwlwifi: mld: Fix MLO scan timing

2026-04-11T12:29:22+00:00

[ Upstream commit ec66ec6a5a8f53e7c70085749e8d68f4431c630f ] Calculate MLO scan start time based on actual scan start notification from firmware instead of recording time when scan command is sent. Currently, MLO scan start time was captured immediately after sending the scan command to firmware. However, the actual scan start time may differ due to the FW being busy with a previous scan. In that case, the link selection code will think that the MLO scan is too old, and will warn. To fix it, Implement start scan notification handling to capture the precise moment when firmware begins the scan operation. Fixes: 9324731b9985 ("wifi: iwlwifi: mld: avoid selecting bad links") Signed-off-by: Pagadala Yesu Anjaneyulu Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260324113316.4c56b8bac533.I6e656d8cc30bb82c96aabadedd62bd67f4c46bf9@changeid Signed-off-by: Sasha Levin

net: intel: fix PCI device ID conflict between i40e and ipw2200

2026-03-04T12:21:41+00:00

[ Upstream commit d03e094473ecdeb68d853752ba467abe13e1de44 ] The ID 8086:104f is matched by both i40e and ipw2200. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. Fix this by taking advantage of the fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Cc: stable@vger.kernel.org Acked-by: Johannes Berg Signed-off-by: Ethan Nelson-Moore Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260210021235.16315-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

wifi: iwlegacy: add missing mutex protection in il3945_store_measurement()

2026-03-04T12:20:29+00:00

[ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()

2026-03-04T12:20:29+00:00

[ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mld: Fix primary link selection logic

2026-03-04T12:20:27+00:00

[ Upstream commit 7a749db26cab2334d5b356ac31e6f1147c7682da ] When assigning emlsr.primary with emlsr.selected_primary we are checking if BIT(mld_vif->emlsr.selected_links) are a part of vif->active_links. This is incorrect as emlsr.selected_links is a bitmap of possibly two selected links. Therefore, performing the BIT() operation on it does not yield any meaningful result and almost always leads to incorrect primary link selection. Additionally, we cannot rely on vif->active_links at this stage of the link switch flow because it contains both the removed links and also the newly added links. For example, if we had selected links in the past (0x11) and we now select links because of TTLM/debugfs (0x100), vif->active_links will now be (0x111) and primary link will be 0, while 0 is not even an active link. Thus, we create our own bitmap of final active links. Signed-off-by: Nidhish A N Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111193638.38b2e14e3a20.Ie81a88dfff0c5d2becedabab8398702808f6b1bf@changeid Signed-off-by: Sasha Levin

wifi: iwlwifi: mld: fix chandef start calculation

2026-03-04T12:20:27+00:00

[ Upstream commit d2fcdf36554316cc51f7928b777944738d06e332 ] A link pair in which both links are in 5 GHz can be used for EMLSR only if they are separated enough. To check this condition we calculate the start and the end of the chandefs of both links in the pair and do some checks. But the calculation of the start/end of the chandef is currently done by subtracting/adding half the bandwidth from/to the control channel's center frequency, when it should really be subtracted/added from/to the center frequency of the entire chandef. Fix the wrong calculation. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111193638.2138fdb99bd5.I4d2e5957b22482a57b1d6ca444e90fcf73bf2cab@changeid Signed-off-by: Sasha Levin

wifi: iwlwifi: fix 22000 series SMEM parsing

2026-03-04T12:20:27+00:00

[ Upstream commit 58192b9ce09b0f0f86e2036683bd542130b91a98 ] If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c5175b3f0757bea5aa232454f1ac@changeid Signed-off-by: Sasha Levin