kernel/git/stable/linux.git/net/wireless/mlme.c, branch linux-7.2.y

wifi: cfg80211: validate assoc response length before status and IE access

2026-07-07T07:31:38+00:00

cfg80211_rx_assoc_resp() initialises the status and response-IE fields of cfg80211_connect_resp_params from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched resp_ie after the unsafe initialiser had already run. Defer resp_ie, resp_ie_len, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared free_bss label for the abandon paths. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260707025336.22557-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: validate rx/tx MLME callback frame lengths before access

2026-07-07T07:29:26+00:00

cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260707025336.22557-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: ensure UHR ML-PM flag is consistent

2026-05-05T12:49:01+00:00

We check that extended MLD capabilities and operations are consistent across APs in an AP MLD, but didn't check reserved fields since they could be defined to differ. Check bit 8 now since it's defined by UHR to be consistent. Link: https://patch.msgid.link/20260428110915.34158027395b.I9df13d3f2588d79294559fad64182acc9edf3f30@changeid Signed-off-by: Johannes Berg

wifi: cfg80211/mac80211: Add NL80211_IFTYPE_PD for PD PASN and PMSR operations

2026-05-05T11:28:57+00:00

Add a new wdev-only interface type NL80211_IFTYPE_PD to support Proximity Detection (PD) operations such as PASN and peer measurement operations. This interface type operates without a netdev, similar to P2P_DEVICE and NAN interfaces. Implement support across cfg80211 and mac80211 layers with PD-specific checks gated by the NL80211_EXT_FEATURE_SECURE_RTT feature flag, management frame registration and transmission capabilities, and proper channel context handling where PD interfaces are excluded from bandwidth calculations. Update mac80211 to recognize the new interface type in the relevant paths for this management-only interface. PD discovery can be performed on any available interface, such as NL80211_IFTYPE_STATION. If PD/PMSR uses the MAC address of an existing interface type, such as NL80211_IFTYPE_STATION, then pairing and measurement shall use that same interface. If PD/PMSR uses a different MAC address, such as a random MAC address, then pairing and measurement can be performed on a new NL80211_IFTYPE_PD interface created with that random MAC address. Signed-off-by: Peddolla Harshavardhan Reddy Link: https://patch.msgid.link/20260420090856.2152905-4-peddolla.reddy@oss.qualcomm.com [fix comment style] Signed-off-by: Johannes Berg

wifi: cfg80211: indicate (Re)Association frame encryption to userspace

2026-05-05T10:09:19+00:00

In SME-in-driver mode, the driver handles the entire (re)association exchange. Userspace (e.g., wpa_supplicant) currently has no explicit indication of whether the (re)association exchange was encrypted, making it difficult to distinguish EPP (Enhanced Privacy Protection, IEEE 802.11bi) associations from non-EPP associations. When (Re)Association frame encryption is used, the (Re)Association Response frame must contain a Key Delivery element as specified in IEEE P802.11bi/D4.0, Table 9-65. Userspace must process this element only when the (Re)Association Response frame is actually encrypted. Processing it unconditionally for unencrypted frames leads to incorrect behavior. Without an explicit indication from the driver, userspace cannot determine whether encryption was used and whether the Key Delivery element is valid. Add a new flag attribute NL80211_ATTR_ASSOC_ENCRYPTED and a corresponding field "assoc_encrypted" in cfg80211_connect_resp_params to indicate that both the (Re)Association Request and Response frames are transmitted encrypted over the air. For mac80211-based drivers, extend cfg80211_rx_assoc_resp_data with the assoc_encrypted field as well, which is then propagated to cfg80211_connect_resp_params. Pass the flag to userspace via NL80211_CMD_CONNECT event. Signed-off-by: Kavita Kavita Link: https://patch.msgid.link/20260504123624.529218-2-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg

wifi: cfg80211: allow protected action frame TX for NAN

2026-03-25T19:56:56+00:00

Allow transmitting protected dual of public action frames on NAN device and NAN data interfaces, since NAN action frames may be protected and can be sent on both. Signed-off-by: Avraham Stern Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260318143604.73801a92180c.I16000c3e1e2bbc320457db1ac728d789bb2f36c6@changeid Signed-off-by: Johannes Berg

wifi: nl80211: allow reporting spurious NAN Data frames

2026-03-25T19:56:55+00:00

Currently we have this ability for AP and GO. But it is now needed also for NAN_DATA mode - as per Wi-Fi Aware (TM) 4.0 specification 6.2.5: "If a NAN Device receives a unicast NAN Data frame destined for it, but with A1 address and A2 address that are not assigned to the NDP, it shall discard the frame, and should send a Data Path Termination NAF to the frame transmitter" To allow this, change NL80211_CMD_UNEXPECTED_FRAME to support also NAN_DATA, so drivers can report such cases and the user space can act accordingly. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260108102921.5cf9f1351655.I47c98ce37843730b8b9eb8bd8e9ef62ed6c17613@changeid Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260219094725.3846371-6-miriam.rachel.korenblit@intel.com Link: https://patch.msgid.link/20260318123926.206536-9-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg

wifi: cfg80211: events, report background radar

2026-03-02T08:10:28+00:00

In case we report radar event add also information this is connected with background one, so user mode application like hostapd, could check it and behave correctly. Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20260206171830.553879-4-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: set and report chandef CAC ongoing

2026-03-02T08:10:28+00:00

Allow to track and check CAC state from user mode by simple check phy channels eg. using iw phy1 channels command. This is done for regular CAC and background CAC. It is important for background CAC while we can start it from any app (eg. iw or hostapd). Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20260206171830.553879-3-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: fix background CAC

2026-03-02T08:10:28+00:00

Fix: - Send CAC_ABORT event when background CAC is canceled - Cancel CAC done workqueue when radar is detected - Release background wdev ownership when CAC is aborted or passed - Clean lower layer background radar state when CAC is aborted or passed - Prevent sending abort event when radar event is sent Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20260206171830.553879-2-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg