summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)Author
9 hoursMerge branch 'for-next' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
8 dayswifi: mac80211: Route (Re)association req/response to per-STA queueIlan Peer
An association request or response frame is generally delivered to the driver without a TX queue object. However, with drivers that do encryption offload and couple the key with a transmit queue, this means that the frames are not being encrypted. Fix this by routing the association frames to the management TXQ. This will allow the driver to set up the required resources before transmitting the association frame, e.g., set up keys etc. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260706222925.febcc62f485c.Iff932880e4b98232cbf6ba405fbb90d650a85381@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: ibss: wait for in-flight TX on disconnectPagadala Yesu Anjaneyulu
While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronize_net() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues. Move netif_carrier_off() to occur before sta_info_flush() during IBSS disconnect, and add synchronize_net() if flushing didn't, so that the synchronize_net() always happens between turning the carrier off and telling the driver, avoiding this race. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260706223751.da1ce439cc93.If5cf482f87ab98ce66dd48724e24c81fed236d3f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: recalculate rx_nss on IBSS peer capability updateShahar Tzarfati
When IBSS peer capabilities change, rates_updated is set to true in ieee80211_update_sta_info(), but rx_nss is never recalculated. For peers with HT/VHT, this leaves rx_nss at 0 instead of the correct value, causing drivers to use incorrect rate scaling parameters. The root cause is that the commit below moved NSS initialisation out of rate_control_rate_init() into explicit call sites, but missing the rates_updated path in ieee80211_update_sta_info(). Fix this by calling ieee80211_sta_init_nss_bw_capa() before rate_control_rate_init() when peer capabilities are updated, consistent with the other IBSS call sites added by that commit. Fixes: e5ad38a9b261 ("wifi: mac80211: clean up STA NSS handling") Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260706222724.422adfd57b71.I5a47f65c5e38a221712f5203e5c8040304b382b5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: fix memory leak in ieee80211_register_hw()Dawei Feng
If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed. Fixes: 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support") Cc: stable@vger.kernel.org Reviewed-by: Zilin Guan <zilin@seu.edu.cn> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn> Link: https://patch.msgid.link/20260706143507.146131-1-dawei.feng@seu.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lockCen Zhang
ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip Fixes: 397a7a24ef8c ("mac80211: free ps->bc_buf skbs on vlan device stop") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/20260706140841.581566-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: validate deauth frame length before reason accessZhao Li
ieee80211_rx_mgmt_deauth() reads the deauth reason code before checking that the fixed field is actually present in the received frame. Validate the deauth frame length first and only then read the reason code. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260612185042.66260-6-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: avoid non-S1G AID fallback for S1G assocZhao Li
When assoc_data->s1g is set and no AID Response element is present, falling back to mgmt->u.assoc_resp.aid reads the non-S1G association-response layout. Keep the fallback for non-S1G only. If a successful S1G association response omits the AID Response element, abandon the association instead of proceeding with AID 0. Initialize aid to 0 for other S1G responses so the later mask and logging flow keeps a defined value without reading the non-S1G layout. Fixes: 2a8a6b7c4cb0 ("wifi: mac80211: handle station association response with S1G") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260612152440.25955-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: validate extension-frame layout before RXZhao Li
Extension frames only have the extension header at the regular 802.11 header offset. The generic RX path can still reach helpers and interface dispatch code that read regular header address fields before unsupported extension subtypes are dropped. mac80211 currently only handles S1G beacon extension frames. Drop other extension subtypes before they can reach regular-header RX processing. For S1G beacons, linearize the SKB with the management-frame path and require the fixed S1G beacon header, including optional fixed fields indicated by frame control, before generic RX dispatch. Route S1G beacons through the station/default-link RX path without regular-header station lookup. Avoid regular-header address reads in the mac80211 RX paths that process S1G extension beacons, including accept-frame, duplicate-detection, address-copy, and MLO address-translation paths. Also make ieee80211_get_bssid() length-safe before returning the S1G source-address pointer. Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons") Cc: stable@vger.kernel.org Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260611161943.91069-5-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: defer link RX stats percpu free to RCUMaoyi Xie
sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: sta_info_free_link(&alloc->info); kfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain. Fixes: c71420db653a ("wifi: mac80211: RCU-ify link STA pointers") Link: https://lore.kernel.org/r/20260626080158.3589711-1-maoyixie.tju@gmail.com Suggested-by: Johannes Berg <johannes@sipsolutions.net> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Link: https://patch.msgid.link/20260627083028.3826810-1-maoyixie.tju@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: free ack status frame on TX header build failureZhiling Zou
ieee80211_build_hdr() stores an ACK status frame before it has finished all validation and header construction. If a later error path is taken, the transmit skb is freed but the stored ACK status frame remains in local->ack_status_frames. This can happen for control port frames when the requested MLO link ID does not match the link selected for a non-MLO station. Repeated failures can fill the ACK status IDR and leave pending ACK frames until hardware teardown. Remove any stored ACK status frame before returning an error after it has been inserted into the IDR. Fixes: a729cff8ad51 ("mac80211: implement wifi TX status") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Link: https://patch.msgid.link/9de0423da840e92084915b8f92e66a421245c4b8.1782462409.git.roxy520tt@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: fix fils_discovery double free on alloc failureXiang Mei
ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon(). Fixes: 3b1c256eb4ae ("wifi: mac80211: fixes in FILS discovery updates") Reported-by: Weiming Shi <bestswngs@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260621093532.884188-2-xmei5@asu.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failureXiang Mei
ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon(). Fixes: 3b1c256eb4ae ("wifi: mac80211: fixes in FILS discovery updates") Reported-by: Weiming Shi <bestswngs@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260621093532.884188-1-xmei5@asu.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: cfg80211/nl80211: add STA-mode peer probingPriyansha Tiwari
Add NL80211_EXT_FEATURE_PROBE_AP to allow drivers to advertise support for probing the associated AP from STA/P2P-client mode. Extend nl80211_probe_peer() to accept STA/P2P-client interfaces when the driver advertises NL80211_EXT_FEATURE_PROBE_AP; in that case the MAC attribute must be omitted (the peer is implied by the association). Update cfg80211_probe_status() to accept an optional peer address and a link_id parameter (-1 for non-MLO), and include NL80211_ATTR_MLO_LINK_ID in the event when link_id >= 0. Update all callers. Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com> Link: https://patch.msgid.link/20260611062225.2144241-3-pritiwa@qti.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
8 dayswifi: nl80211/cfg80211: rename probe_client to probe_peerPriyansha Tiwari
Rename NL80211_CMD_PROBE_CLIENT to NL80211_CMD_PROBE_PEER in the UAPI enum and retain NL80211_CMD_PROBE_CLIENT as a compatibility alias. Rename the .probe_client cfg80211_ops callback to .probe_peer and update all in-tree users (wil6210, mwifiex) and mac80211 so the tree continues to build after this change. Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com> Link: https://patch.msgid.link/20260611062225.2144241-2-pritiwa@qti.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
9 dayswifi: mac80211: allocate backup ieee80211_nan_sched_cfg off stackArnd Bergmann
The ieee80211_nan_sched_cfg structure is too large to keep on the per thread stack: net/mac80211/nan.c:251:5: error: stack frame size (1560) exceeds limit (1536) in 'ieee80211_nan_set_local_sched' [-Werror,-Wframe-larger-than] 251 | int ieee80211_nan_set_local_sched(struct ieee80211_sub_if_data *sdata, Allocate this dynamically using kmalloc_obj() to reduce the stack usage of this function to a manageable 344 bytes for the same configuration. Fixes: 589c06e8fdee ("wifi: mac80211: add NAN local schedule support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260611130100.3387714-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10Merge tag 'wireless-next-2026-06-10' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a few last updates, notably: - b43: new support for an 11n device - mt76: - mt792x broken usb transport detection - mt7921 regd improvements - mt7927 support - iwlwifi: - more kunit tests - FW version updates - ath12k: WDS support - rtw89: - RTL8922AU support - USB 3 mode switch for performance - better monitor radiotap support - RTL8922DE preparations - cfg80211/mac80211: - update UHR to D1.4, UHR DBE support - finally remove 5/10 MHz support - S1G rate reporting - multicast encapsulation offload * tag 'wireless-next-2026-06-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (285 commits) b43: add RF power offset for N-PHY r8 + radio 2057 r8 b43: add channel info table for N-PHY r8 + radio 2057 r8 b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8 b43: support radio 2057 rev 8 b43: route d11 corerev 22 to 24-bit indirect radio access b43: add d11 core revision 0x16 to id table b43: add firmware mappings for rev22 rfkill: Replace strcpy() with memcpy() wifi: brcmfmac: flowring: simplify flow allocation wifi: brcm80211: change current_bss to value wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits wifi: ath: Update copyright in testmode_i.h wifi: ath10k: Update Qualcomm copyrights wifi: ath11k: Update Qualcomm copyrights wifi: ath12k: Update Qualcomm copyrights wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks wifi: mt76: mt7921: assert sniffer on chanctx change wifi: mt76: mt7996: fix potential tx_retries underflow wifi: mt76: mt7925: fix potential tx_retries underflow ... ==================== Link: https://patch.msgid.link/20260610103637.179340-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05wifi: mac80211: Add 802.3 multicast encapsulation offload supportTamizh Chelvam Raja
mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add multicast to unicast support for 802.3 pathTamizh Chelvam Raja
mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit()Tamizh Chelvam Raja
Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: fold tid_ampdu_rx allocations into a flexible arrayRosen Penev
Convert the separately-allocated reorder_buf pointer to a C99 flexible array member at the end of struct tid_ampdu_rx, with both the sk_buff_head and the jiffies timestamp in each array element. This collapses three allocations into one and removes the corresponding kfree() pairs from the error and free paths. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260605005627.317194-1-rosenp@gmail.com [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Fix -Wc23-extensions in hwmp_route_info_get()Nathan Chancellor
When building with a version of clang that supports '-fms-anonymous-structs' (which will be used by the kernel instead of the wider '-fms-extensions'), there are a couple warnings after some recent mesg_hwmp.c changes: net/mac80211/mesh_hwmp.c:373:3: error: label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions] 373 | struct ieee80211_mesh_hwmp_preq_top *preq_elem_top = | ^ net/mac80211/mesh_hwmp.c:390:3: error: label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions] 390 | struct ieee80211_mesh_hwmp_prep_top *prep_elem_top = | ^ 2 errors generated. Enclose the switch case blocks in braces to clear up the warning. Fixes: a91c65cb99d1 ("wifi: mac80211: Use struct instead of macro for PREP frame") Fixes: 4ac20bd40b7d ("wifi: mac80211: Use struct instead of macro for PREQ frame") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260604-mac80211-mesh_hwmp-fix-c23-extensions-v1-1-25a64d6ce541@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.1-rc7). Silent conflicts: net/wireless/nl80211.c cb9959ab5f99 ("wifi: cfg80211: enforce HE/EHT cap/oper consistency") a384ae969902 ("wifi: cfg80211: move AP HT/VHT/... operation to beacon info") https://lore.kernel.org/aiGJDaHV4UlCexIQ@sirena.org.uk Conflicts: drivers/net/wireless/intel/iwlwifi/mld/ap.c a342c99cb70d ("wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED") 9bf1b409afc7 ("wifi: iwlwifi: mld: send tx power constraints before link activation") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk drivers/net/wireless/intel/iwlwifi/pcie/drv.c 093305d801fa ("wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used") e2323929a68a ("wifi: iwlwifi: pcie: add debug print for resume flow if powered off") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk Adjacent changes: drivers/net/ethernet/airoha/airoha_eth.c b38cae85d1c4 ("net: airoha: Fix use-after-free in metadata dst teardown") ec6c391bcca7 ("net: airoha: Introduce airoha_gdm_dev struct") drivers/net/ethernet/microchip/lan743x_main.c 8173d22b211f ("net: lan743x: permit VLAN-tagged packets up to configured MTU") e3c6508a46f5 ("net: lan743x: avoid netdev-based logging before netdev registration") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04wifi: mac80211: fix monitor mode frame capture for real chanctx drivers傅继晗
Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection behaviour") restored the monitor injection fallback for drivers using chanctx emulation but explicitly deferred drivers that transitioned to real chanctx ops. mt76 falls in that category and still drops every injected frame when monitor coexists with another interface. When the monitor has no chanctx of its own, fall back to the only chanctx in flight if there is exactly one. Refuse if multiple are present: picking arbitrarily would inject on an unrelated channel. Emulated and real chanctx drivers both flow through this fallback, since emulation always presents zero or one chanctx in local->chanctx_list. Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor VIF on the same phy + aireplay-ng deauth from the monitor) on mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a Kali VM with MT7921U passthrough as the closest match to the original reporter's setup. None reproduced the hang seen against the earlier attempt at this fix (<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1 on lore in March. Cc: <stable+noautosel@kernel.org> # causes some older drivers to crash Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com> Closes: https://github.com/morrownr/USB-WiFi/issues/682 Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by: 傅继晗 <fjhhz1997@gmail.com> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/5c2760bd9bc34616bf7892848872522254dd1ce5.1780513445.git.lucid_duck@justthetip.ca Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04wifi: mac80211: Free keys associated with NAN DeviceIlan Peer
A NAN Device interface can have keys associated with it, e.g., IGTK and BIGTK used for Tx. When a NAN Device interface is stopped, we need to clear these keys. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260603143624.c6c771885383.I929410cb8efec4fab2d42ead396bfefaf9f803f1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: AP: handle DBE for clientsJohannes Berg
In AP mode, track the BSS non-DBE bandwidth and apply that to all non-DBE clients, then track OMP updates from the clients and enable/disable DBE accordingly. For now don't send a response, clients need to have a timer anyway (it's up to the driver to set the right timeout in UHR capabilities.) Link: https://patch.msgid.link/20260529102644.be84f2b055cc.I4d2c067dfe54c47621d5a872ca07a0e754d6c20f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: parse and apply UHR DBE channelJohannes Berg
When a UHR AP has DBE enabled, parse the channel and apply it to the chandef. Apply for TX only after the OMP response (or timeout) so that the AP doesn't receive frames with DBE width before the station completed transition to DBE. Link: https://patch.msgid.link/20260529102644.cb810f212128.Ife37c2673251346e84e4250b242b31f0895520ab@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: refactor link STA bandwidth updateJohannes Berg
There's similar code in two places in HT and HE, and we need to add the same again for UHR. Rename ieee80211_link_sta_rc_update_omi() to ieee80211_link_sta_update_rc_bw() and move it to sta_info.c and update existing code that can use it to do so. Link: https://patch.msgid.link/20260529102644.577c2f304d33.I09df4fce83c4e3e6deddfecbea74ffdbeedb4927@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: explain ieee80211_determine_chan_mode() parsingJohannes Berg
Looking through element parsing behaviour for multi-BSSID and multi-link, this one seemed odd. Add a comment that explains why it's written this way. Link: https://patch.msgid.link/20260529102644.25f75c4df338.I1f1f17cc0ae8e413659654d4bbaa34260ef68e2c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: mlme: allow UHR only with MLOJohannes Berg
UHR requires MLO, not just formally but also in order for the client to understand AP BSS parameter changes, since the Critical Update Counter is inside the Multi- Link Element. Require MLO for UHR connections to avoid otherwise needed complexity such as not enabling any feature that would require tracking critical updates. Link: https://patch.msgid.link/20260529102644.43817ce87042.If4562ae9c5ca83339b397d9a344b68631cb17c4a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: always expose multi-link elementJohannes Berg
During beacon processing, the parser is always called with a BSS to find the correct multi-BSSID profile (if any) and therefore never attempts to parse a multi-link element. This means the code to handle cross-link CSA can effectively never do anything. Fix this by parsing the multi-link element in the regular parser as well. Fixes: 7ef8f6821d16 ("wifi: mac80211: mlme: handle cross-link CSA") Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260529102644.2a74b2659f50.I8f9454bf5e05c419a9b1eb23ecad302a6bf63fbb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: use local ml_basic_elem in parsingJohannes Berg
There's no need to store this pointer on the heap, it's only used in a single function. Move it there. Also clarify the comment referencing it, ml_basic_elem is not actually relevant (any more.) Link: https://patch.msgid.link/20260529102644.50187b7a6ca2.Ifef23bda96651eed0f5cd2c3ecd4817d2fb08af4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: clarify beacon parsing with MBSSID/EMAJohannes Berg
When connected to a non-transmitting BSS of multiple BSSID set with EMA, the correct profile for the connection isn't always present in the beacon. Indicate this in the parser and use the information to not check everything in beacon processing, since the information might not be correct if taken only from the transmitted BSS. Link: https://patch.msgid.link/20260529102644.97527a7dfd7b.Iecd0ef578b85a5a0057538cfff5fdff41d19b7ea@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: rename "multi_link_inner" variableJohannes Berg
This variable name seems a bit misleading now (I added it myself a year ago or so), it indicates that the parsing is happening on the inner elements of a multi-link element. Rename it to "inside_multilink" to clarify. Link: https://patch.msgid.link/20260529102644.7ccd55a411cf.I4101e1cfd133a2ce2374340712da8bb1f0292a40@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: clean up return in ieee802_11_find_bssid_profile()Johannes Berg
There's no need to define 'profile_len' at the outer scope and initialize it, move it where needed and just return 0 if nothing can be found. Link: https://patch.msgid.link/20260529102644.46f25609ddef.I9e651a0018e66953f4fb508f784188e00351c07f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: unify link STA removal in vif link removalJohannes Berg
There are multiple cases where interface links are removed and the station links need to be removed with them, e.g. in mlme.c we have both received and transmitted multi-link reconfiguration, doing the two things in different order, the former deleting STA links when the vif link change may still fail. It's also not clear that userspace (hostapd) couldn't, at least in theory, remove a link from an interface without removing the station links first, or even leave stations that aren't MLO-capable, using that link. Unify this code into ieee80211_vif_update_links() so that it always happens, always happens in the right order and is transactional (i.e. failures are handled correctly.) Link: https://patch.msgid.link/20260529102644.c352f73a4658.I7219a5d72dab2abcecea9b5c52e7eb7a50e68d9b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: basic S1G rx rate reporting supportLachlan Hodges
Introduce basic rate encoding/decoding for S1G stas such that the usermode rx reporting is relevant as it currently uses VHT calculations which are obviously wildy different to S1G. Sample iw output (with the associated iw patches applied): Connected to 0c:bf:74:00:21:c4 (on wlan0) SSID: wifi_halow freq: 923.500 RX: 7325230 bytes (4756 packets) TX: 190044 bytes (2238 packets) signal: -38 dBm rx bitrate: 43.3 MBit/s S1G-MCS 9 8MHz short GI S1G-NSS 1 tx bitrate: 43.3 MBit/s S1G-MCS 9 8MHz short GI S1G-NSS 1 bss flags: dtim period: 1 beacon int: 100 Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260602062224.1792985-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Add KUnit test for ieee80211_mesh_perr_size_okMasashi Honma
Add a kunit test for ieee80211_mesh_perr_size_ok(), checking various success and failure cases. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-9-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Add KUnit test for ieee80211_mesh_prep_size_okMasashi Honma
Add a kunit test for ieee80211_mesh_prep_size_ok(), checking various success and failure cases. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-8-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Add KUnit test for ieee80211_mesh_preq_size_okMasashi Honma
Add a kunit test for ieee80211_mesh_preq_size_ok(), checking various success and failure cases. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-7-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Fix PERR frame processingMasashi Honma
There are no issues with the PERR processing itself; however, to maintain consistency with the previous PREQ/PREP code modifications, I will create a new mesh_path_parse_error_frame() function to separately implement the frame format validation and the "not supported" check. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-6-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Fix overread in PREP frame processingMasashi Honma
When the AF flag is enabled, hwmp_prep_frame_process() overreads orig_addr by 2 bytes. Since this occurs within the socket buffer, it does not read across memory boundaries and therefore poses no security risk; however, we will fix it as a precaution. In this fix, a new function mesh_path_parse_reply_frame() is established to separate the implementation of frame format validation and the check for unsupported features. This is intended to facilitate future work when implementing the currently unsupported parts. Assisted-by: Claude:Sonnet 4.6 Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-5-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Fix overread in PREQ frame processingMasashi Honma
When the AF flag is enabled, hwmp_preq_frame_process() overreads target_addr by 2 bytes. Since this occurs within the socket buffer, it does not read across memory boundaries and therefore poses no security risk; however, we will fix it as a precaution. In this fix, a new function mesh_path_parse_request_frame() is established to separate the implementation of frame format validation and the check for unsupported features. This is intended to facilitate future work when implementing the currently unsupported parts. Assisted-by: Claude:Sonnet 4.6 Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-4-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Use struct instead of macro for PERR frameMasashi Honma
The existing PERR_IE_* macros access HWMP PERR frame fields via hardcoded byte offsets. Each PERR destination entry contains an optional 6-byte AE (Address Extension) address followed by a reason code, making offset-based access error-prone. Introduce typed packed C structs to represent the PERR frame layout: - ieee80211_mesh_hwmp_perr: top-level frame containing TTL and destination count - ieee80211_mesh_hwmp_perr_dst: per-destination entry with optional AE address and variable-position reason code Add ieee80211_mesh_hwmp_perr_get_rcode() to locate the reason code in each destination entry depending on whether the AE flag is set. This refactoring makes the PERR processing code consistent with the struct-based approach adopted for PREQ and PREP in preceding patches. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-3-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Use struct instead of macro for PREP frameMasashi Honma
The existing PREP_IE_* macros access HWMP PREP frame fields via hardcoded byte offsets. When the AE (Address Extension) flag is set, an additional 6 bytes appear mid-frame, making the offset arithmetic error-prone. Introduce typed packed C structs to represent the PREP frame layout: - ieee80211_mesh_hwmp_prep_top: fixed fields before the optional AE address - ieee80211_mesh_hwmp_prep_bottom: fields after the optional AE address Add ieee80211_mesh_hwmp_prep_get_bottom() to locate the bottom struct correctly based on whether the AE flag is set. This preparatory refactoring is needed to fix a 2-byte overread of orig_addr in hwmp_prep_frame_process() when AE is enabled, which is addressed in a subsequent patch. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-2-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Use struct instead of macro for PREQ frameMasashi Honma
The existing PREQ_IE_* macros access HWMP PREQ frame fields via hardcoded byte offsets. When the AE (Address Extension) flag is set, an additional 6 bytes appear mid-frame, and the macros handle this with conditional arithmetic (e.g., AE_F_SET(x) ? x + N+6 : x + N). This approach obscures the frame layout and is prone to miscalculation. Introduce typed packed C structs to represent the PREQ frame layout: - ieee80211_mesh_hwmp_preq_top: fixed fields before the optional AE address - ieee80211_mesh_hwmp_preq_bottom: fields after the optional AE address - ieee80211_mesh_hwmp_preq_target: per-target fields Add ieee80211_mesh_hwmp_preq_get_bottom() to locate the bottom struct correctly based on whether the AE flag is set. This preparatory refactoring is needed to fix a 2-byte overread of target_addr in hwmp_preq_frame_process() when AE is enabled, which is addressed in a subsequent patch. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-1-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: remove 5/10 MHz channel codeJohannes Berg
Now that cfg80211 refuses all attempts to use 5/10 MHz channels, all of this code is unreachable; remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260529084502.4e5a9350206c.I2f6169a067ddd1b5e234668fcb6e07957fafacf2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: report assoc_link_id in station info for non-MLD STAs on MLD APFelix Fietkau
When a non-MLD station associates with an MLD AP, it does so on a specific link. However, sta_set_sinfo() never sets mlo_params_valid, so nl80211 never emits NL80211_ATTR_MLO_LINK_ID in get_station / dump_station responses. Userspace has no way to determine which link a non-MLD STA is associated on. Set mlo_params_valid to 1 and assoc_link_id to sta->deflink.link_id, when valid_links is set. Also set the mld_addr copy only for MLD STAs, so that non-MLD STAs get a zeroed mld_addr as documented. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20260528105042.835284-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-02wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotapDeepanshu Kartikey
When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: info->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds. Reported-by: syzbot+8e0622f6d9446420271f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8e0622f6d9446420271f Fixes: ef246a1480cc ("wifi: mac80211: support antenna control in injection") Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260531011721.102941-1-kartikey406@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-28wifi: mac80211: fix channel evacuation logicMiri Korenblit
When we try to assign a chanctx to a link, if ieee80211_find_or_create_chanctx() failed, we try to evacuate a NAN channel and call it again. This logic is broken: In case there are not enough chanctxs we will fail earlier, when we check ieee80211_check_combinations(). To fix this, do the following in case ieee80211_check_combinations() failed: - check if there is a NAN channel that can be evacuated - make ieee80211_check_combinations() not consider the chanctx of that NAN channel, so we pretend that it was already evacuated - If now ieee80211_check_combinations() is successful, we know that it helped, and we can remove that NAN channel for real. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260527224745.5f7b10505145.I1712bc64f9eec9c99f05994208ad124624a29f1c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-14 21:34:03 +0000