kernel/linux.git/net/wireless/util.c, branch v6.1.168

wifi: cfg80211: Fix bitrate calculation overflow for HE rates

2026-02-11T12:37:23+00:00

[ Upstream commit a3034bf0746d88a00cceda9541534a5721445a24 ] An integer overflow occurs in cfg80211_calculate_bitrate_he() when calculating bitrates for high throughput HE configurations. For example, with 160 MHz bandwidth, HE-MCS 13, HE-NSS 4, and HE-GI 0, the multiplication (result * rate->nss) overflows the 32-bit 'result' variable before division by 8, leading to significantly underestimated bitrate values. The overflow occurs because the NSS multiplication operates on a 32-bit integer that cannot accommodate intermediate values exceeding 4,294,967,295. When overflow happens, the value wraps around, producing incorrect bitrates for high MCS and NSS combinations. Fix this by utilizing the 64-bit 'tmp' variable for the NSS multiplication and subsequent divisions via do_div(). This approach preserves full precision throughout the entire calculation, with the final value assigned to 'result' only after completing all operations. Signed-off-by: Veerendranath Jakkam Link: https://patch.msgid.link/20260109-he_bitrate_overflow-v1-1-95575e466b6e@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

cfg80211: Update Transition Disable policy during port authorization

2026-01-11T14:18:58+00:00

[ Upstream commit 0ff57171d6d225558c81a69439d5323e35b40549 ] In case of 4way handshake offload, transition disable policy updated by the AP during EAPOL 3/4 is not updated to the upper layer. This results in mismatch between transition disable policy between the upper layer and the driver. This patch addresses this issue by updating transition disable policy as part of port authorization indication. Signed-off-by: Vinayak Yadawad Signed-off-by: Johannes Berg Stable-dep-of: a519be2f5d95 ("wifi: mac80211: do not use old MBSSID elements") Signed-off-by: Sasha Levin

wifi: prevent A-MSDU attacks in mesh networks

2025-07-17T16:32:08+00:00

commit 737bb912ebbe4571195c56eba557c4d7315b26fb upstream. This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks. This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt. This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field. It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented. Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef Link: https://patch.msgid.link/20250616004635.224344-1-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

wifi: cfg80211: fix receiving mesh packets without RFC1042 header

2024-08-29T15:30:55+00:00

commit fec3ebb5ed299ac3a998f011c380f2ded47f4866 upstream. Fix ethernet header length field after stripping the mesh header Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/CT5GNZSK28AI.2K6M69OXM9RW5@syracuse/ Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Reported-and-tested-by: Nicolas Escande Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20230711115052.68430-1-nbd@nbd.name Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

wifi: cfg80211: check A-MSDU format more carefully

2024-08-29T15:30:21+00:00

[ Upstream commit 9ad7974856926129f190ffbe3beea78460b3b7cc ] If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present. Reported-by: syzbot+d050d437fe47d479d210@syzkaller.appspotmail.com Link: https://msgid.link/20240226203405.a731e2c95e38.I82ce7d8c0cc8970ce29d0a39fdc07f1ffc425be4@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: add a workaround for receiving non-standard mesh A-MSDU

2024-08-29T15:30:21+00:00

[ Upstream commit 6e4c0d0460bd32ca9244dff3ba2d2da27235de11 ] At least ath10k and ath11k supported hardware (maybe more) does not implement mesh A-MSDU aggregation in a standard compliant way. 802.11-2020 9.3.2.2.2 declares that the Mesh Control field is part of the A-MSDU header (and little-endian). As such, its length must not be included in the subframe length field. Hardware affected by this bug treats the mesh control field as part of the MSDU data and sets the length accordingly. In order to avoid packet loss, keep track of which stations are affected by this and take it into account when converting A-MSDU to 802.3 + mesh control packets. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20230213100855.34315-5-nbd@nbd.name Signed-off-by: Johannes Berg Stable-dep-of: 9ad797485692 ("wifi: cfg80211: check A-MSDU format more carefully") Signed-off-by: Sasha Levin

wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces

2024-08-29T15:30:21+00:00

[ Upstream commit 986e43b19ae9176093da35e0a844e65c8bf9ede7 ] The current mac80211 mesh A-MSDU receive path fails to parse A-MSDU packets on mesh interfaces, because it assumes that the Mesh Control field is always directly after the 802.11 header. 802.11-2020 9.3.2.2.2 Figure 9-70 shows that the Mesh Control field is actually part of the A-MSDU subframe header. This makes more sense, since it allows packets for multiple different destinations to be included in the same A-MSDU, as long as RA and TID are still the same. Another issue is the fact that the A-MSDU subframe length field was apparently accidentally defined as little-endian in the standard. In order to fix this, the mesh forwarding path needs happen at a different point in the receive path. ieee80211_data_to_8023_exthdr is changed to ignore the mesh control field and leave it in after the ethernet header. This also affects the source/dest MAC address fields, which now in the case of mesh point to the mesh SA/DA. ieee80211_amsdu_to_8023s is changed to deal with the endian difference and to add the Mesh Control length to the subframe length, since it's not covered by the MSDU length field. With these changes, the mac80211 will get the same packet structure for converted regular data packets and unpacked A-MSDU subframes. The mesh forwarding checks are now only performed after the A-MSDU decap. For locally received packets, the Mesh Control header is stripped away. For forwarded packets, a new 802.11 header gets added. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20230213100855.34315-4-nbd@nbd.name [fix fortify build error] Signed-off-by: Johannes Berg Stable-dep-of: 9ad797485692 ("wifi: cfg80211: check A-MSDU format more carefully") Signed-off-by: Sasha Levin

wifi: cfg80211: factor out bridge tunnel / RFC1042 header check

2024-08-29T15:30:21+00:00

[ Upstream commit 9f718554e7eacea62d3f972cae24d969755bf3b6 ] The same check is done in multiple places, unify it. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20230213100855.34315-2-nbd@nbd.name Signed-off-by: Johannes Berg Stable-dep-of: 9ad797485692 ("wifi: cfg80211: check A-MSDU format more carefully") Signed-off-by: Sasha Levin

wifi: cfg80211: move A-MSDU check in ieee80211_data_to_8023_exthdr

2024-08-29T15:30:21+00:00

[ Upstream commit 0f690e6b4dcd7243e2805a76981b252c2d4bdce6 ] When parsing the outer A-MSDU header, don't check for inner bridge tunnel or RFC1042 headers. This is handled by ieee80211_amsdu_to_8023s already. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20230213100855.34315-1-nbd@nbd.name Signed-off-by: Johannes Berg Stable-dep-of: 9ad797485692 ("wifi: cfg80211: check A-MSDU format more carefully") Signed-off-by: Sasha Levin

wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()

2024-08-03T06:49:06+00:00

[ Upstream commit bcbd771cd5d68c0c52567556097d75f9fc4e7cd6 ] Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Baochen Qiang Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin