summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)AuthorFilesLines
2025-07-23wifi: mac80211: fix WARN_ON for monitor mode on some devicesJohannes Berg1-1/+12
On devices without WANT_MONITOR_VIF (and probably without channel context support) we get a WARN_ON for changing the per-link setting of a monitor interface. Since we already skip AP_VLAN interfaces and MONITOR with WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update the settings, catch this in the link change code instead of the warning. Reported-by: Martin Kaistra <martin.kaistra@linutronix.de> Link: https://lore.kernel.org/r/a9de62a0-28f1-4981-84df-253489da74ed@linutronix.de/ Fixes: c4382d5ca1af ("wifi: mac80211: update the right link for tx power") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: fix unassigned variable accessAntonio Quartulli1-4/+3
In ieee80211_latest_active_link_conn_timeout() we loop over all sta->links in order to compute the timeout expiring last across all links. Such timeout is stored in `latest_timeout` which is used in the time_after() comparison before having been initialized. Fix this behaviour by initializing the variable to `jiffies` and adapt surrouding conditions accordingly. Note that the caller assumed latest_timeout to be 0 if no active link was found. This is not appropriate because jiffies=0 is a valid (and recurrent, although not often) point in time. By using `jiffies` as default value for latest_timeout, we can fix the caller as well. Address-Coverity-ID: 1647986 ("Uninitialized variables (UNINIT)") Fixes: 1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO") Signed-off-by: Antonio Quartulli <antonio@mandelbit.com> Link: https://patch.msgid.link/20250722120634.3501-1-antonio@mandelbit.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: don't require cipher and keylen in gtk rekeyMiri Korenblit1-3/+33
ieee80211_add_gtk_rekey receives a keyconf as an argument, and the cipher and keylen are taken from there to the new allocated key. But in rekey, both the cipher and the keylen should be the same as of the old key, so let ieee80211_add_gtk_rekey find those, so drivers won't have to fill it in. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250721214922.3c5c023bfae9.Ie6594ae2b4b6d5b3d536e642b349046ebfce7a5d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon()Kees Cook1-1/+1
While I caught the need for setting cnt early in nl80211_parse_rnr_elems() in the original annotation of struct cfg80211_rnr_elems with __counted_by, I missed a similar pattern in ieee80211_copy_rnr_beacon(). Fix this by moving the cnt assignment to before the loop. Fixes: 7b6d7087031b ("wifi: cfg80211: Annotate struct cfg80211_rnr_elems with __counted_by") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20250721182521.work.540-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21wifi: cfg80211/mac80211: report link ID for unexpected framesMichael-CY Lee1-5/+5
The upper layer may require the link ID to properly handle unexpected frames. For instance, if hostapd, operating as an AP MLD, receives a data frame from a non-associated STA, it must send deauthentication to the link on which the STA is operating. Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Reviewed-by: Money Wang <money.wang@mediatek.com> Link: https://patch.msgid.link/20250721065159.1740992-1-michael-cy.lee@mediatek.com [edit commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() ↵Michael-CY Lee1-1/+17
based on frequency For broadcast frames, every interface might have to process it and therefore the link_id cannot be determined in the driver. In mac80211, when the frame is about to be forwarded to each interface, we can use the member "freq" in struct ieee80211_rx_status to determine the "link_id" for each interface. Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Reviewed-by: Money Wang <money.wang@mediatek.com> Link: https://patch.msgid.link/20250721062929.1662700-1-michael-cy.lee@mediatek.com [simplify, remove unnecessary link->conf check] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21wifi: mac80211: remove ieee80211_remove_keyMiri Korenblit1-26/+1
It is no longer used, remove it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250721091956.e964ceacd85c.Idecab8ef161fa58e000b3969bc936399284b79f0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18Reapply "wifi: mac80211: Update skb's control block key in ↵Remi Pommarel1-0/+1
ieee80211_tx_dequeue()" This reverts commit 0937cb5f345c ("Revert "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()""). This commit broke TX with 802.11 encapsulation HW offloading, now that this is fixed, reapply it. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/66b8fc39fb0194fa06c9ca7eeb6ffe0118dcb3ec.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key()Remi Pommarel1-0/+6
With 802.11 encapsulation offloading, ieee80211_tx_h_select_key() is called on 802.3 frames. In that case do not try to use skb data as valid 802.11 headers. Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/linux-wireless/20250410215527.3001-1-spasswolf@web.de Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/1af4b5b903a5fca5ebe67333d5854f93b2be5abe.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Don't call fq_flow_idx() for management framesAlexander Wetzel1-1/+2
skb_get_hash() can only be used when the skb is linked to a netdev device. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames") Link: https://patch.msgid.link/20250717162547.94582-3-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Do not schedule stopped TXQsAlexander Wetzel1-1/+3
Ignore TXQs with the flag IEEE80211_TXQ_STOP when scheduling a queue. The flag is only set after all fragments have been dequeued and won't allow dequeueing other frames as long as the flag is set. For drivers using ieee80211_txq_schedule_start() this prevents an loop trying to push the queued frames while IEEE80211_TXQ_STOP is set: After setting IEEE80211_TXQ_STOP the driver will call ieee80211_return_txq(). Which calls __ieee80211_schedule_txq(), detects that there sill are frames in the queue and immediately restarts the stopped TXQ. Which can't dequeue any frame and thus starts over the loop. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Link: https://patch.msgid.link/20250717162547.94582-2-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support returning the S1G short beacon skbLachlan Hodges1-11/+84
When short beaconing is enabled, check the value of the sb_count to determine whether we are to send a long beacon or short beacon. sb_count represents the number of short beacons until the next long beacon, where if its value is 0 we are to send a long beacon. The value is then reset to the long beacon period, which represents the number of beacon intervals between each long beacon. The decrement process follows the same cadence as the decrement of the DTIM count value. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-5-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support initialising current S1G short beacon indexLachlan Hodges5-9/+40
Introduce the sb_count variable which tracks the number of beacon intervals until the next long beacon. To initialise this value, we find the current short beacon index into this period which represents the number of short beacons left to send before the next long beacon. We use the same TSF value used to initialise the DTIM count to ensure the short beacon count and DTIM count are in sync as its common for the long beacon period and DTIM period to be equivalent. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-4-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support initialising an S1G short beaconing BSSLachlan Hodges2-2/+73
Introduce the ability to parse the short beacon data and long beacon period. The long beacon period represents the number of beacon intervals between each long beacon transmission. Additionally, as a BSS cannot change its configuration such that short beaconing is dynamically disabled/enabled without tearing down the interface - we ensure we have an existing short beacon before performing the update. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-3-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: reject TDLS operations when station is not associatedMoon Hee Lee1-1/+1
syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated. Reported-by: syzbot+f73f203f8c9b19037380@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f73f203f8c9b19037380 Fixes: 81dd2b882241 ("mac80211: move TDLS data to mgd private part") Tested-by: syzbot+f73f203f8c9b19037380@syzkaller.appspotmail.com Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com> Link: https://patch.msgid.link/20250715230904.661092-2-moonhee.lee.ca@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: extend connection monitoring for MLOMaharaja Kennadyrajan1-24/+52
Currently, reset connection monitor (ieee80211_sta_reset_conn_monitor()) timer is handled only for non-AP non-MLD STA and do not support non-AP MLD STA. The current implementation checks for the CSA active and update the monitor timer with the timeout value of deflink and reset the timer based on the deflink's timeout value else schedule the connection loss work when the deflink is timed out and it won't work for the non-AP MLD STA. Handle the reset connection monitor timer for non-AP MLD STA by updating the monitor timer with the timeout value which is determined based on the link that will expire last among all the links in MLO. If at least one link has not timed out, the timer is updated accordingly with the latest timeout value else schedule the connection loss work when all links have timed out. Remove the MLO-related WARN_ON() checks in the beacon and connection monitoring logic code paths as they support MLO now. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-5-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: extend beacon monitoring for MLOMaharaja Kennadyrajan1-5/+36
Currently, reset beacon monitor (ieee80211_sta_reset_beacon_monitor()) timer is handled only for non-AP non-MLD STA and do not support non-AP MLD STA. When the beacon loss occurs in non-AP MLD STA with the current implementation, it is treated as a single link and the timer will reset based on the timeout of the deflink, without checking all the links. Check the CSA flags for all the links in the MLO and decide whether to schedule the work queue for beacon loss. If any of the links has CSA active, then beacon loss work is not scheduled. Also, call the functions ieee80211_sta_reset_beacon_monitor() and ieee80211_sta_reset_conn_monitor() from ieee80211_csa_switch_work() only when all the links are CSA active. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-4-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Add link iteration macro for link data with rcu_dereferenceMaharaja Kennadyrajan1-0/+13
Currently, the existing macro for_each_link_data() uses sdata_dereference() which requires the wiphy lock. This lock cannot be used in atomic or RCU read-side contexts, such as in the RX path. Introduce a new macro, for_each_link_data_rcu(), that iterates over link of sdata using rcu_dereference(), making it safe to use in RCU contexts. This allows callers to access link data without requiring the wiphy lock. The macro takes into account the vif.valid_links bitmap and ensures only valid links are accessed safely. Callers are responsible for ensuring that rcu_read_lock() is held when using this macro. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-3-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: fix macro scoping in for_each_link_dataAditya Kumar Singh1-1/+3
The for_each_link_data() macro currently declares a local variable __sdata directly, which could lead to compiler warnings or errors when reused in the same function or within switch-case blocks due to variable redefinition or invalid scoping. To address this, restructure the macro to use an outer for-loop that runs only once, allowing safe declaration of __sdata without polluting the outer scope. This ensures compatibility with static analyzers. No functional changes; this is purely a cleanup to improve macro hygiene. Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-2-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: cfg80211/mac80211: remove wrong scan request n_channelsJohannes Berg1-1/+0
This (partially) reverts commits - 838c7b8f1f27 ("wifi: nl80211: Avoid address calculations via out of bounds array indexing") - f1d3334d604c ("wifi: cfg80211: sme: init n_channels before channels[] access") - 82bbe02b2500 ("wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request") These commits all set the structure to be in an inconsistent state, setting n_channels to some value before them actually being filled in. That's fine for what the code does now, but with the removal of __counted_by() in 444020f4bf06 ("wifi: cfg80211: remove scan request n_channels counted_by") it's no longer needed and it does leave a bit of a landmine there since breaking out of some code to send the scan or something would leave it wrong. Remove the now superfluous n_channels settings. Link: https://patch.msgid.link/20250718103237.59510b2384c5.Ied5ba9c5c49efc008f4491c8ca7a45858a83f064@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: use RCU-safe iteration in ieee80211_csa_finishMaharaja Kennadyrajan2-1/+16
The ieee80211_csa_finish() function currently uses for_each_sdata_link() to iterate over links of sdata. However, this macro internally uses wiphy_dereference(), which expects the wiphy->mtx lock to be held. When ieee80211_csa_finish() is invoked under an RCU read-side critical section (e.g., under rcu_read_lock()), this leads to a warning from the RCU debugging framework. WARNING: suspicious RCU usage net/mac80211/cfg.c:3830 suspicious rcu_dereference_protected() usage! This warning is triggered because wiphy_dereference() is not safe to use without holding the wiphy mutex, and it is being used in an RCU context without the required locking. Fix this by introducing and using a new macro, for_each_sdata_link_rcu(), which performs RCU-safe iteration over sdata links using list_for_each_entry_rcu() and rcu_dereference(). This ensures that the link pointers are accessed safely under RCU and eliminates the warning. Fixes: f600832794c9 ("wifi: mac80211: restructure tx profile retrieval for MLO MBSSID") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250711033846.40455-1-maharaja.kennadyrajan@oss.qualcomm.com [unindent like the non-RCU macro] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: parse unsolicited broadcast probe response dataYuvarani V1-0/+12
During commands like channel switch and color change, the updated unsolicited broadcast probe response template may be provided. However, this data is not parsed or acted upon in mac80211. Add support to parse it and set the BSS changed flag BSS_CHANGED_UNSOL_BCAST_PROBE_RESP so that drivers could take further action. Signed-off-by: Yuvarani V <quic_yuvarani@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250710-update_unsol_bcast_probe_resp-v2-2-31aca39d3b30@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't use TPE data from assoc responseJohannes Berg1-5/+28
Since there's no TPE element in the (re)assoc response, trying to use the data from it just leads to using the defaults, even though the real values had been set during authentication from the discovered BSS information. Fix this by simply not handling the TPE data in assoc response since it's not intended to be present, if it changes later the necessary changes will be made by tracking beacons later. As a side effect, by passing the real frame subtype, now print a correct value for ML reconfiguration responses. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.caa1ca853f5a.I588271f386731978163aa9d84ae75d6f79633e16@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: handle WLAN_HT_ACTION_NOTIFY_CHANWIDTH asyncMiri Korenblit4-30/+80
If this action frame, with the value of IEEE80211_HT_CHANWIDTH_ANY, arrives right after a beacon that changed the operational bandwidth from 20 MHz to 40 MHz, then updating the rate control bandwidth to 40 can race with updating the chanctx width (that happens in the beacon proccesing) back to 40 MHz: cpu0 cpu1 ieee80211_rx_mgmt_beacon ieee80211_config_bw ieee80211_link_change_chanreq (*)ieee80211_link_update_chanreq ieee80211_rx_h_action (**)ieee80211_sta_cur_vht_bw (***) ieee80211_recalc_chanctx_chantype in (**), the maximum between the capability width and the bss width is returned. But the bss width was just updated to 40 in (*), so the action frame handling code will increase the width of the rate control before the chanctx was increased (in ***), leading to a FW error (at least in iwlwifi driver. But this is wrong regardless). Fix this by simply handling the action frame async, so it won't race with the beacon proccessing. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218632 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.bb9dc6f36c35.I39782d6077424e075974c3bee4277761494a1527@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: simplify __ieee80211_rx_h_amsdu() loopJohannes Berg1-15/+8
The loop handling individual subframes can be simplified to not use a somewhat confusing goto inside the loop. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.a217a1e8c667.I5283df9627912c06c8327b5786d6b715c6f3a4e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't mark keys for inactive links as uploadedMiri Korenblit1-1/+2
During resume, the driver can call ieee80211_add_gtk_rekey for keys that are not programmed into the device, e.g. keys of inactive links. Don't mark such a key as uploaded to avoid removing it later from the driver/device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.655094412b0b.Iacae31af3ba2a705da0a9baea976c2f799d65dc4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: only assign chanctx in reconfigMiri Korenblit1-4/+6
At the end of reconfig we are activating all the links that were active before the error. During the activation, _ieee80211_link_use_channel will unassign and re-assign the chanctx from/to the link. But we only need to do the assign, as we are re-building the state as it was before the reconfig. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.6245c3ae7031.Ia5f68992c7c112bea8a426c9339f50c88be3a9ca@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: clean up cipher suite handlingJohannes Berg2-54/+17
Under the previous commit's assumption that FIPS isn't supported by hardware, we don't need to modify the cipher suite list, but just need to use the software one instead of the driver's in this case, so clean up the code. Also fix it to exclude TKIP in this case, since that's also dependent on RC4. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.cff427e8f8a5.I744d1ea6a37e3ea55ae8bc3e770acee734eff268@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't send keys to driver when fips_enabledJohannes Berg2-1/+8
When fips_enabled is set, don't send any keys to the driver (including possibly WoWLAN KEK/KCK material), assuming that no device exists with the necessary certifications. If this turns out to be false in the future, we can add a HW flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.e5eebc2b19d8.I968ef8c9ffb48d464ada78685bd25d22349fb063@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: remove ieee80211_link_unreserve_chanctx() return valueJohannes Berg2-6/+4
All the paths that could return an error are considered misuses of the function and WARN already, and none of the callers ever check the return value. Remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.5b436ee3c20c.Ieff61ec510939adb5fe6da4840557b649b3aa820@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't unreserve never reserved chanctxJohannes Berg1-1/+2
If a link has no chanctx, indicating it is an inactive link that we tracked CSA for, then attempting to unreserve the reserved chanctx will throw a warning and fail, since there never was a reserved chanctx. Skip the unreserve. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.022192f4b1ae.Ib58156ac13e674a9f4d714735be0764a244c0aae@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: make VHT opmode NSS ignore a debug messageJohannes Berg1-2/+3
There's no need to always print it, it's only useful for debugging specific client issues. Make it a debug message. Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/linux-wireless/20250529070922.3467-1-pmenzel@molgen.mpg.de/ Link: https://patch.msgid.link/20250708105849.22448-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski5-14/+31
Cross-merge networking fixes after downstream PR (net-6.16-rc6-2). No conflicts. Adjacent changes: drivers/net/wireless/mediatek/mt76/mt7925/mcu.c c701574c5412 ("wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw scan") b3a431fe2e39 ("wifi: mt76: mt7925: fix off by one in mt7925_mcu_hw_scan()") drivers/net/wireless/mediatek/mt76/mt7996/mac.c 62da647a2b20 ("wifi: mt76: mt7996: Add MLO support to mt7996_tx_check_aggr()") dc66a129adf1 ("wifi: mt76: add a wrapper for wcid access with validation") drivers/net/wireless/mediatek/mt76/mt7996/main.c 3dd6f67c669c ("wifi: mt76: Move RCU section in mt7996_mcu_add_rate_ctrl()") 8989d8e90f5f ("wifi: mt76: mt7996: Do not set wcid.sta to 1 in mt7996_mac_sta_event()") net/mac80211/cfg.c 58fcb1b4287c ("wifi: mac80211: reject VHT opmode for unsupported channel widths") 037dc18ac3fb ("wifi: mac80211: add support for storing station S1G capabilities") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10wifi: mac80211: add the virtual monitor after reconfig completeMiri Korenblit1-5/+4
In reconfig we add the virtual monitor in 2 cases: 1. If we are resuming (it was deleted on suspend) 2. If it was added after an error but before the reconfig (due to the last non-monitor interface removal). In the second case, the removal of the non-monitor interface will succeed but the addition of the virtual monitor will fail, so we add it in the reconfig. The problem is that we mislead the driver to think that this is an existing interface that is getting re-added - while it is actually a completely new interface from the drivers' point of view. Some drivers act differently when a interface is re-added. For example, it might not initialize things because they were already initialized. Such drivers will - in this case - be left with a partialy initialized vif. To fix it, add the virtual monitor after reconfig_complete, so the driver will know that this is a completely new interface. Fixes: 3c3e21e7443b ("mac80211: destroy virtual monitor interface across suspend") Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233451.648d39b041e8.I2e37b68375278987e303d6c00cc5f3d8334d2f96@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-10wifi: mac80211: always initialize sdata::key_listMiri Korenblit1-2/+2
This is currently not initialized for a virtual monitor, leading to a NULL pointer dereference when - for example - iterating over all the keys of all the vifs. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233400.8dcefe578497.I4c90a00ae3256520e063199d7f6f2580d5451acf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: don't complete management TX on SAE commitJohannes Berg1-1/+8
When SAE commit is sent and received in response, there's no ordering for the SAE confirm messages. As such, don't call drivers to stop listening on the channel when the confirm message is still expected. This fixes an issue if the local confirm is transmitted later than the AP's confirm, for iwlwifi (and possibly mt76) the AP's confirm would then get lost since the device isn't on the channel at the time the AP transmit the confirm. For iwlwifi at least, this also improves the overall timing of the authentication handshake (by about 15ms according to the report), likely since the session protection won't be aborted and rescheduled. Note that even before this, mgd_complete_tx() wasn't always called for each call to mgd_prepare_tx() (e.g. in the case of WEP key shared authentication), and the current drivers that have the complete callback don't seem to mind. Document this as well though. Reported-by: Jan Hendrik Farr <kernel@jfarr.cc> Closes: https://lore.kernel.org/all/aB30Ea2kRG24LINR@archlinux/ Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609213232.12691580e140.I3f1d3127acabcd58348a110ab11044213cf147d3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: cfg80211/mac80211: implement dot11ExtendedRegInfoSupportSomashekhar Puttagangaiah3-0/+60
Implement dot11ExtendedRegInfoSupport to advertise non-AP station regulatory power capability as part of regulatory connectivity element in (Re)Association request frames so that AP can achieve maximum client connectivity. Control field which was interpreted using value of 3-bits B5 to B3, now uses value of 4-bits B6 to B3 to interpret the type of AP. Hence update IEEE80211_HE_6GHZ_OPER_CTRL_REG_INFO to parse 4-bits control field. If older AP still updates only 3-bits value of control field, station can still interpret the value as per section E.2.7 of IEEE 802.11 REVme D7.0 and support the appropriate AP type. Also update IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP as the value of standard power AP is changed to 8 instead of 4 so that AP can support both LPI AP and SP AP to maximize the connectivity with stations. For backward compatibility, keeping value 4 as old AP by limiting it to SP AP only. Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@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/20250609213232.90cdef116aad.I85da390fbee59355e3855691933e6a5e55c47ac4@changeid [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: send extended MLD capa/ops if AP has itJohannes Berg1-9/+45
Currently the code only sends extended MLD capa/ops in strict mode, but if the AP has it then it should also be able to parse it. There could be cases where the AP doesn't have it but we would want to advertise it (e.g. if the AP supports nothing but we want to have BTM.), but given the broken deployed APs out there right now this is the best we can do. Signed-off-by: Johannes Berg <johannes.berg@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/20250609213232.c9b8b3a6ca77.I1153d4283d1fbb9e5db60e7b939cc133a6345db5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: copy first_part into HW scanBenjamin Berg1-1/+2
cfg80211 now reports whether this is the first part of a scan. Copy that information into the driver request. Signed-off-by: Benjamin Berg <benjamin.berg@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/20250609213231.63f6078bd7be.Ia6e5cee945e6d9617c2f427552d89d23c92eee83@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: remove DISALLOW_PUNCTURING_5GHZ codeJohannes Berg2-6/+1
Since iwlwifi was the only driver using this and no longer does, we can remove all this code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609213231.4dff5fb8890f.Ie531f912b252a0042c18c0734db50c3afe1adfb5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: fix deactivated link CSAJohannes Berg1-0/+17
If the link is deactivated and the CSA completes, then that needs to update the link station's bandwidth (only the AP STA can exist at this point, no TDLS on inactive links) and set the CSA to no longer be active. Fix this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609213231.07f120cf687d.I5a868c501ee73fcc2355d61c2ee06e5f444b350f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: add mandatory bitrate support for 6 GHzSomashekhar Puttagangaiah1-1/+2
When a new station is added, ensure that mandatory bit-rates are enabled for 6 GHz band. Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@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/20250609213231.4aecd7f3b85b.I33a54872a3267c9f6155ce537d6c9c2a31c3f117@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: remove spurious blank lineJohannes Berg1-1/+0
ieee80211_process_ml_reconf_resp() has a blank line between an if statement and the covered code, remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609213231.a1f4ceae700d.I1d7aae17cc466c1648f31c42b935165db85d2809@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: verify state before connectionMiri Korenblit1-8/+14
ieee80211_prep_connection is supposed to be called when both bitmaps (valid_links and active_links) are cleared. Make sure of it and WARN if this is not the case, to avoid weird issues. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250609213231.f616c7b693df.Ie983155627ad0d2e7c19c30ce642915246d0ed9d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: Fix uninitialized variable with __free() in ieee80211_ml_epcs()Pagadala Yesu Anjaneyulu1-1/+1
The cleanup attribute runs kfree() when the variable goes out of scope. There is a possibility that the link_elems variable is uninitialized if the loop ends before an assignment is made to this variable. This leads to uninitialized variable bug. Fix this by assigning link_elems to NULL. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@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/20250609213231.eeacd3738a7b.I0f876fa1359daeec47ab3aef098255a9c23efd70@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09wifi: mac80211: avoid weird state in error pathMiri Korenblit1-1/+8
If we get to the error path of ieee80211_prep_connection, for example because of a FW issue, then ieee80211_vif_set_links is called with 0. But the call to drv_change_vif_links from ieee80211_vif_update_links will probably fail as well, for the same reason. In this case, the valid_links and active_links bitmaps will be reverted to the value of the failing connection. Then, in the next connection, due to the logic of ieee80211_set_vif_links_bitmaps, valid_links will be set to the ID of the new connection assoc link, but the active_links will remain with the ID of the old connection's assoc link. If those IDs are different, we get into a weird state of valid_links and active_links being different. One of the consequences of this state is to call drv_change_vif_links with new_links as 0, since the & operation between the bitmaps will be 0. Since a removal of a link should always succeed, ignore the return value of drv_change_vif_links if it was called to only remove links, which is the case for the ieee80211_prep_connection's error path. That way, the bitmaps will not be reverted to have the value from the failing connection and will have 0, so the next connection will have a good state. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250609213231.ba2011fb435f.Id87ff6dab5e1cf757b54094ac2d714c656165059@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-08wifi: mac80211: fix rx link assignment for non-MLO stationsHari Chandrakanthan1-3/+9
Currently, ieee80211_rx_data_set_sta() does not correctly handle the case where the interface supports multiple links (MLO), but the station does not (non-MLO). This can lead to incorrect link assignment or unexpected warnings when accessing link information. Hence, add a fix to check if the station lacks valid link support and use its default link ID for rx->link assignment. If the station unexpectedly has valid links, fall back to the default link. This ensures correct link association and prevents potential issues in mixed MLO/non-MLO environments. Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250630084119.3583593-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-07wifi: mac80211: reject VHT opmode for unsupported channel widthsMoon Hee Lee1-0/+14
VHT operating mode notifications are not defined for channel widths below 20 MHz. In particular, 5 MHz and 10 MHz are not valid under the VHT specification and must be rejected. Without this check, malformed notifications using these widths may reach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due to invalid input. This issue was reported by syzbot. Reject these unsupported widths early in sta_link_apply_parameters() when opmode_notif is used. The accepted set includes 20, 40, 80, 160, and 80+80 MHz, which are valid for VHT. While 320 MHz is not defined for VHT, it is allowed to avoid rejecting HE or EHT clients that may still send a VHT opmode notification. Reported-by: syzbot+ededba317ddeca8b3f08@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ededba317ddeca8b3f08 Fixes: 751e7489c1d7 ("wifi: mac80211: expose ieee80211_chan_width_to_rx_bw() to drivers") Tested-by: syzbot+ededba317ddeca8b3f08@syzkaller.appspotmail.com Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com> Link: https://patch.msgid.link/20250703193756.46622-2-moonhee.lee.ca@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-07wifi: mac80211: fix non-transmitted BSSID profile searchJohannes Berg1-4/+2
When the non-transmitted BSSID profile is found, immediately return from the search to not return the wrong profile_len when the profile is found in a multiple BSSID element that isn't the last one in the frame. Fixes: 5023b14cf4df ("mac80211: support profile split between elements") Reported-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://patch.msgid.link/20250630154501.f26cd45a0ecd.I28e0525d06e8a99e555707301bca29265cf20dc8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-07wifi: mac80211: clear frame buffer to never leak stackJohannes Berg1-0/+3
In disconnect paths paths, local frame buffers are used to build deauthentication frames to send them over the air and as notifications to userspace. Some internal error paths (that, given no other bugs, cannot happen) don't always initialize the buffers before sending them to userspace, so in the presence of other bugs they can leak stack content. Initialize the buffers to avoid the possibility of this happening. Suggested-by: Zhongqiu Han <quic_zhonhan@quicinc.com> Link: https://patch.msgid.link/20250701072213.13004-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>