linux.git/net/wireless/util.c, branch v6.16

wifi: prevent A-MSDU attacks in mesh networks

2025-07-07T08:54:13+00:00

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

wifi: cfg80211: expose cfg80211_chandef_get_width()

2025-03-12T08:50:24+00:00

This can be just a trivial inline, to simplify some code.
Expose it, and also use it in util.c where it wasn't
previously available.

Reviewed-by: Miriam Rachel Korenblit 
Link: https://patch.msgid.link/20250311122534.c5c3b4af9a74.Ib25cf60f634dc359961182113214e5cdc3504e9c@changeid
Signed-off-by: Johannes Berg

Merge tag 'wireless-next-2024-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

2024-12-20T02:54:07+00:00

Kalle Valo says:

====================
wireless-next patches for v6.14

Multi-Link Operation implementation continues, both in stack and in
drivers. Otherwise it has been relatively quiet.

Major changes:

cfg80211/mac80211
 - define wiphy guard
 - get TX power per link
 - EHT 320 MHz channel support for mesh

ath11k
 - QCA6698AQ support

ath9k
 - RX inactivity detection

rtl8xxxu
 - add more USB device IDs

rtw88
 - add more USB device IDs
 - enable USB RX aggregation and USB 3 to improve performance

rtw89
 - PowerSave flow for Multi-Link Operation

* tag 'wireless-next-2024-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (121 commits)
  wifi: wlcore: sysfs: constify 'struct bin_attribute'
  wifi: brcmfmac: clarify unmodifiable headroom log message
  wifi: brcmfmac: add missing header include for brcmf_dbg
  wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()
  wifi: qtnfmac: fix spelling error in core.h
  wifi: rtw89: phy: add dummy C2H event handler for report of TAS power
  wifi: rtw89: 8851b: rfk: remove unnecessary assignment of return value of _dpk_dgain_read()
  wifi: rtw89: 8852c: rfk: refine target channel calculation in _rx_dck_channel_calc()
  wifi: rtlwifi: pci: wait for firmware loading before releasing memory
  wifi: rtlwifi: fix memory leaks and invalid access at probe error path
  wifi: rtlwifi: destroy workqueue at rtl_deinit_core
  wifi: rtlwifi: remove unused check_buddy_priv
  wifi: rtw89: 8922a: update format of RFK pre-notify H2C command v2
  wifi: rtw89: regd: update regulatory map to R68-R51
  wifi: rtw89: 8852c: disable ER SU when 4x HE-LTF and 0.8 GI capability differ
  wifi: rtw89: disable firmware training HE GI and LTF
  wifi: rtw89: ps: update data for firmware and settings for hardware before/after PS
  wifi: rtw89: ps: refactor channel info to firmware before entering PS
  wifi: rtw89: ps: refactor PS flow to support MLO
  wifi: mwifiex: decrease timeout waiting for host sleep from 10s to 5s
  ...
====================

Link: https://patch.msgid.link/20241219185709.774EDC4CECE@smtp.kernel.org
Signed-off-by: Jakub Kicinski

wifi: cfg80211: define and use wiphy guard

2024-12-04T15:10:52+00:00

Define a guard for the wiphy mutex, and use it in
most code in cfg80211, though not all due to some
interaction with RTNL and/or indentation.

Suggested-by: Jeff Johnson 
Reviewed-by: Jeff Johnson 
Signed-off-by: Johannes Berg 
Link: https://patch.msgid.link/20241122094225.88765cbaab65.I610c9b14f36902e75e1d13f0db29f8bef2298804@changeid
Signed-off-by: Johannes Berg

wifi: cfg80211: clear link ID from bitmap during link delete after clean up

2024-12-03T10:28:20+00:00

Currently, during link deletion, the link ID is first removed from the
valid_links bitmap before performing any clean-up operations. However, some
functions require the link ID to remain in the valid_links bitmap. One
such example is cfg80211_cac_event(). The flow is -

nl80211_remove_link()
    cfg80211_remove_link()
        ieee80211_del_intf_link()
            ieee80211_vif_set_links()
                ieee80211_vif_update_links()
                    ieee80211_link_stop()
                        cfg80211_cac_event()

cfg80211_cac_event() requires link ID to be present but it is cleared
already in cfg80211_remove_link(). Ultimately, WARN_ON() is hit.

Therefore, clear the link ID from the bitmap only after completing the link
clean-up.

Signed-off-by: Aditya Kumar Singh 
Link: https://patch.msgid.link/20241121-mlo_dfs_fix-v2-1-92c3bf7ab551@quicinc.com
Signed-off-by: Johannes Berg

wifi: cfg80211: add option for vif allowed radios

2024-10-23T14:44:10+00:00

This allows users to prevent a vif from affecting radios other than the
configured ones. This can be useful in cases where e.g. an AP is running
on one radio, and triggering a scan on another radio should not disturb it.

Changing the allowed radios list for a vif is supported, but only while
it is down.

While it is possible to achieve the same by always explicitly specifying
a frequency list for scan requests and ensuring that the wrong channel/band
is never accidentally set on an unrelated interface, this change makes
multi-radio wiphy setups a lot easier to deal with for CLI users.

By itself, this patch only enforces the radio mask for scanning requests
and remain-on-channel. Follow-up changes build on this to limit configured
frequencies.

Signed-off-by: Felix Fietkau 
Link: https://patch.msgid.link/eefcb218780f71a1549875d149f1196486762756.1728462320.git-series.nbd@nbd.name
Signed-off-by: Johannes Berg

wifi: mac80211, cfg80211: miscellaneous spelling fixes

2024-10-08T19:52:09+00:00

Correct spelling here and there as suggested by codespell.

Signed-off-by: Dmitry Antipov 
Link: https://patch.msgid.link/20240913084919.118862-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg

wifi: cfg80211: Use kmemdup_array instead of kmemdup for multiple allocation

2024-08-27T08:28:56+00:00

Let the kememdup_array() take care about multiplication and possible
overflows.

Signed-off-by: Yu Jiaoliang 
Reviewed-by: Christophe JAILLET 
Link: https://patch.msgid.link/20240822074743.1366561-1-yujiaoliang@vivo.com
Signed-off-by: Johannes Berg

wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority

2024-08-27T08:28:54+00:00

According to RFC8325 4.3, Multimedia Streaming: AF31(011010, 26),
AF32(011100, 28), AF33(011110, 30) maps to User Priority = 4
and AC_VI (Video).

However, the original code remain the default three Most Significant
Bits (MSBs) of the DSCP, which makes AF3x map to User Priority = 3
and AC_BE (Best Effort).

Fixes: 6fdb8b8781d5 ("wifi: cfg80211: Update the default DSCP-to-UP mapping")
Signed-off-by: hhorace 
Reviewed-by: Guillaume Nault 
Reviewed-by: Ido Schimmel 
Link: https://patch.msgid.link/20240807082205.1369-1-hhoracehsu@gmail.com
Signed-off-by: Johannes Berg

wifi: cfg80211: add helper for checking if a chandef is valid on a radio

2024-07-09T09:36:00+00:00

Check if the full channel width is in the radio's frequency range.

Signed-off-by: Felix Fietkau 
Link: https://patch.msgid.link/7c8ea146feb6f37cee62e5ba6be5370403695797.1720514221.git-series.nbd@nbd.name
[add missing Return: documentation]
Signed-off-by: Johannes Berg