kernel/linux.git/net/wireless/mlme.c, branch v6.6.134

wifi: cfg80211: reject HTC bit for management frames

2025-08-28T14:28:20+00:00

[ Upstream commit be06a8c7313943109fa870715356503c4c709cbc ] Management frames sent by userspace should never have the order/HTC bit set, reject that. It could also cause some confusion with the length of the buffer and the header so the validation might end up wrong. Link: https://patch.msgid.link/20250718202307.97a0455f0f35.I1805355c7e331352df16611839bc8198c855a33f@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: cfg80211: fix assoc response warning on failed links

2023-10-23T11:25:30+00:00

The warning here shouldn't be done before we even set the bss field (or should've used the input data). Move the assignment before the warning to fix it. We noticed this now because of Wen's bugfix, where the bug fixed there had previously hidden this other bug. Fixes: 53ad07e9823b ("wifi: cfg80211: support reporting failed links") Signed-off-by: Johannes Berg

wifi: cfg80211/mac80211: hold link BSSes when assoc fails for MLO connection

2023-09-11T10:16:52+00:00

When connect to MLO AP with more than one link, and the assoc response of AP is not success, then cfg80211_unhold_bss() is not called for all the links' cfg80211_bss except the primary link which means the link used by the latest successful association request. Thus the hold value of the cfg80211_bss is not reset to 0 after the assoc fail, and then the __cfg80211_unlink_bss() will not be called for the cfg80211_bss by __cfg80211_bss_expire(). Then the AP always looks exist even the AP is shutdown or reconfigured to another type, then it will lead error while connecting it again. The detail info are as below. When connect with muti-links AP, cfg80211_hold_bss() is called by cfg80211_mlme_assoc() for each cfg80211_bss of all the links. When assoc response from AP is not success(such as status_code==1), the ieee80211_link_data of non-primary link(sdata->link[link_id]) is NULL because ieee80211_assoc_success()->ieee80211_vif_update_links() is not called for the links. Then struct cfg80211_rx_assoc_resp resp in cfg80211_rx_assoc_resp() and struct cfg80211_connect_resp_params cr in __cfg80211_connect_result() will only have the data of the primary link, and finally function cfg80211_connect_result_release_bsses() only call cfg80211_unhold_bss() for the primary link. Then cfg80211_bss of the other links will never free because its hold is always > 0 now. Hence assign value for the bss and status from assoc_data since it is valid for this case. Also assign value of addr from assoc_data when the link is NULL because the addrs of assoc_data and link both represent the local link addr and they are same value for success connection. Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: Wen Gong Link: https://lore.kernel.org/r/20230825070055.28164-1-quic_wgong@quicinc.com Signed-off-by: Johannes Berg

wifi: cfg80211: reject auth/assoc to AP with our address

2023-08-22T19:40:10+00:00

If the AP uses our own address as its MLD address or BSSID, then clearly something's wrong. Reject such connections so we don't try and fail later. Reported-by: syzbot+2676771ed06a6df166ad@syzkaller.appspotmail.com Signed-off-by: Johannes Berg

wifi: nl80211: Add support for randomizing TA of auth and deauth frames

2023-03-07T10:12:02+00:00

Add support to use a random local address in authentication and deauthentication frames sent to unassociated peer when the driver supports. The driver needs to configure receive behavior to accept frames with random transmit address specified in TX path authentication frames during the time of the frame exchange is pending and such frames need to be acknowledged similarly to frames sent to the local permanent address when this random address functionality is used. This capability allows use of randomized transmit address for PASN authentication frames to improve privacy of WLAN clients. Signed-off-by: Veerendranath Jakkam Link: https://lore.kernel.org/r/20230112012415.167556-2-quic_vjakkam@quicinc.com Signed-off-by: Johannes Berg

wifi: cfg80211: Allow action frames to be transmitted with link BSS in MLD

2023-02-14T11:17:54+00:00

Currently action frames TX only with ML address as A3(BSSID) are allowed in an ML AP, but TX for a non-ML Station can happen in any link of an ML BSS with link BSS address as A3. In case of an MLD, if User-space has provided a valid link_id in action frame TX request, allow transmission of the frame in that link. Signed-off-by: Rameshkumar Sundaram Link: https://lore.kernel.org/r/20230201061602.3918-1-quic_ramess@quicinc.com Signed-off-by: Johannes Berg

wifi: cfg80211: support reporting failed links

2022-10-07T13:23:48+00:00

For assoc and connect result APIs, support reporting failed links; they should still come with the BSS pointer in the case of assoc, so they're released correctly. In the case of connect result, this is optional. Signed-off-by: Johannes Berg

wifi: cfg80211/nl80211: move rx management data into a struct

2022-07-22T12:28:26+00:00

The functions for reporting rx management take many arguments. Collect all the arguments into a struct, which also make it easier to add more arguments if needed. Signed-off-by: Avraham Stern Signed-off-by: Johannes Berg

wifi: mac80211: remove stray printk

2022-07-15T13:05:35+00:00

Unfortunately, a printk snuck into a previous patch, remove it. Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: Johannes Berg

wifi: mac80211: support MLO authentication/association with one link

2022-07-15T09:43:24+00:00

It might seem a bit pointless to do a multi-link operation connection with just a single link, but this is already a big change, so for now, limit MLO connections to a single link. Extending that to multiple links will require * work on parsing the multi-link element with STA profile properly, including element fragmentation; * checking the per-link status in the multi-link element * implementing logic to have active/inactive links to let drivers decide which links should be active; * implementing multicast RX deduplication; * and likely more. For now this is still useful since it lets us do multi-link connections for the purposes of testing APIs and the higher layers such as wpa_supplicant. Signed-off-by: Johannes Berg