kernel/linux.git/net/mac80211/mlme.c, branch linux-7.1.y

wifi: mac80211: consume only present negotiated TTLM maps

2026-05-20T09:20:37+00:00

ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements against the number of link-map entries indicated by link_map_presence. ieee80211_parse_neg_ttlm() must consume the same layout. The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element. The bad bytes land in neg_ttlm->{up,down}link[tid] but are gated by valid_links before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state. Advance the cursor only when the current TID has a map present. Fixes: 8f500fbc6c65 ("wifi: mac80211: process and save negotiated TID to Link mapping request") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260515151719.1317659-2-michael.bommarito@gmail.com Signed-off-by: Johannes Berg

wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs

2026-05-20T09:04:17+00:00

IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID is 0x000f, so link_id extracted from a PRIO_ACCESS ML element PER_STA_PROFILE subelement can be 0..15. sdata->link[] has IEEE80211_MLD_MAX_NUM_LINKS (15) entries (indices 0..14), making index 15 out-of-bounds. A connected WiFi 7 AP can trigger this by sending an EPCS Enable Response action frame with a PER_STA_PROFILE subelement where link_id = 15. The unsolicited-notification path (dialog_token = 0) is reachable any time EPCS is already enabled, without any prior client request. sdata->link[15] reads into the first word of sdata->activate_links_work (a wiphy_work whose embedded list_head is non-NULL after INIT_LIST_HEAD), so the NULL check on the result does not catch the invalid access. The garbage pointer is then passed to ieee80211_sta_wmm_params(), which dereferences link->sdata and crashes the kernel. The same class of bug was fixed for ieee80211_ml_reconfiguration() by commit 162d331d833d ("wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration"). Fixes: de86c5f60839 ("wifi: mac80211: Add support for EPCS configuration") Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260515102908.1653088-1-hossu.alexandru@gmail.com Signed-off-by: Johannes Berg

wifi: mac80211: remove station if connection prep fails

2026-05-06T09:02:57+00:00

If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "new_sta" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs. Cc: stable@vger.kernel.org Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260505151533.c4e52deb06ad.Iafe56cec7de8512626169496b134bce3a6c17010@changeid Signed-off-by: Johannes Berg

wifi: mac80211: skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode

2026-04-27T10:02:40+00:00

Some Xfinity XB8 firmware advertises >1 spatial stream MCS indexes in their basic HT-MCS set. On cards with lower spatial streams, the check would fail, and we'd be stuck with no HT when in fact work fine with its own supported rate. This change makes it so the check is only performed in strict mode. Fixes: 574faa0e936d ("wifi: mac80211: add HT and VHT basic set verification") Signed-off-by: Rio Liu Link: https://patch.msgid.link/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzqotJjD9YW6LGLqk-AZloAueUyHCURilFkuqOh6Ecv8i2KKdSE1ujP3AnbU5QEouVisT1w_V3xdfc=@r26.me Signed-off-by: Johannes Berg

wifi: mac80211: enable MLO support for 4-address mode interfaces

2026-04-07T13:43:02+00:00

The current code does not support establishing MLO connections for interfaces operating in 4-address AP_VLAN mode. MLO bringup is blocked by sanity checks in cfg.c, iface.c, and mlme.c, which prevent MLD initialization when use_4addr is enabled. Remove these restrictions to allow 4-address AP_VLAN interfaces to initialize as part of an MLD and successfully participate in MLO connections. This patch series also adds the necessary changes to support WDS operation in MLO, making these modifications valid. Allow 4-address mode interfaces to: - Proceed with MLD initialization during interface setup - Add MLO links dynamically via ieee80211_add_intf_link() - Establish associations with MLO-capable access points - Support AP_VLAN interfaces with MLO parent APs Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260326164723.553927-4-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg

wifi: mac80211: use ap_addr for 4-address NULL frame destination

2026-04-07T13:43:02+00:00

Currently ieee80211_send_4addr_nullfunc() uses deflink.u.mgd.bssid for addr1 and addr3 fields. In MLO configurations, deflink.u.mgd.bssid represents link 0's BSSID and is not updated when link 0 is not an assoc link. This causes 4-address NULL frames to be sent to the wrong address, preventing WDS AP_VLAN interface creation on the peer AP. To fix this use sdata->vif.cfg.ap_addr instead, which contains the AP's MLD address populated during authentication/association and remains valid regardless of which links are active. This ensures 4-address NULL frames reach the correct AP, allowing proper WDS operation over MLO connections. Co-developed-by: Sathishkumar Muruganandam Signed-off-by: Sathishkumar Muruganandam Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260326164723.553927-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg

wifi: mac80211: handle VHT EXT NSS in ieee80211_determine_our_sta_mode()

2026-04-07T13:41:14+00:00

A station which has a NSS ratio on the number of streams it is capable of in 160MHz VHT operation is supposed to use the 'Extended NSS BW Support' as defined by section '9.4.2.156.2 VHT Capabilities Information field'. This was missing in ieee80211_determine_our_sta_mode() and so we would wrongfully downgrade our bandwidth when connecting to an AP that supported 160MHz with messages such as: [ 37.638346] wlan1: AP XX:XX:XX:XX:XX:XX changed bandwidth in assoc response, new used config is 5280.000 MHz, width 3 (5290.000/0 MHz) Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Signed-off-by: Nicolas Escande Link: https://patch.msgid.link/20260327100256.3101348-1-nico.escande@gmail.com Signed-off-by: Johannes Berg

wifi: mac80211: ignore reserved bits in reconfiguration status

2026-03-25T20:22:02+00:00

The Link ID Info field in the Reconfiguration Status Duple subfield of the Reconfiguration Response frame only uses the lower four bits for the link ID. The upper bits are reserved and should therefore be ignored. Signed-off-by: Benjamin Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260325215404.ab5ccf4bc62e.I9aef8f4fb6f1b06671bb6cf0e2bd4ec6e4c8bda4@changeid Signed-off-by: Johannes Berg

wifi: mac80211: don't consider the sband when processing capabilities

2026-03-24T15:32:16+00:00

In NAN, we have one set of (HT, VHT, HE) capabilities for all bands, which means that we will need to process those capabilities without a given sband. To prepare for that, remove the sband argument from ieee80211_ht_cap_ie_to_sta_ht_cap and ieee80211_he_cap_ie_to_sta_he_cap and pass our own capabilities instead. For ieee80211_vht_cap_ie_to_sta_vht_cap, make the sband argument optional, since it is also used to check if there is at least one channel that supports 80 MHz. (Note that this check doesn't make much sense, but this can be handled in a different patch.) Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260320141504.e42ef1f0eabb.If994d6346f00219437e22043e7bf2395b827b34a@changeid Signed-off-by: Johannes Berg

wifi: mac80211: fix STA link removal during link removal

2026-03-19T08:06:49+00:00

ieee80211_sta_free_link() only frees the link and doesn't unhash it, so it can't be used here. Instead this needs to use ieee80211_sta_remove_link(), which unhashes it. An argument against it was that it also calls the driver and that already happened, but calls to the driver removing a link that's already removed are suppressed, so that's not actually an issue. Use it to fix the hashtable. Reported-and-tested-by: Jouni Malinen Fixes: 84674b03d8bf ("wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work()") Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260318180622.9240067117e9.I45fb2b7f04d75e48d2f3e9c6650ef9f54a314f5b@changeid Signed-off-by: Johannes Berg