kernel/git/next/linux-next.git/net/wireless/util.c, branch master

wifi: cfg80211: ibss: ref BSS entry for joined event

2026-09-09T12:51:27+00:00

When the IBSS is joined, we only record the BSSID/channel in the event and look up the BSS entry when processing it. However, that's racy, e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a warning in the event work: !bss WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440 Workqueue: cfg80211 cfg80211_event_work cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144 cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179 cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393 Do the lookup early (the driver is expected to only join an IBSS that has a BSS entry) and keep a reference to it. Assisted-by: LLM Fixes: 667503ddcb96 ("cfg80211: fix locking") Reported-by: syzbot+7f064ba1704c2466e36d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f064ba1704c2466e36d Link: https://patch.msgid.link/20260904165614.f49a213f0e49.I192bfe738750ebb5f2c4faa3019a428da64cd3ec@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: check IP header size in cfg80211_classify8021d()

2026-09-08T11:09:38+00:00

A frame that looks like IP can be transmitted, but be too short, so the DS field is read incorrectly: BUG: KMSAN: uninit-value in cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 ieee80211_select_queue+0x37a/0x9e0 net/mac80211/wme.c:180 __ieee80211_subif_start_xmit+0x60f/0x1d90 net/mac80211/tx.c:4304 ieee80211_subif_start_xmit+0xa8/0x6d0 net/mac80211/tx.c:4538 ... packet_sendmsg+0x9173/0xa2a0 net/packet/af_packet.c:3108 Use skb_header_pointer() like the MPLS case. Assisted-by: LLM Fixes: e31a16d6f64e ("wireless: move some utility functions from mac80211 to cfg80211") Reported-by: syzbot+878ddc3962f792e9af59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=878ddc3962f792e9af59 Link: https://patch.msgid.link/20260904165614.5e61a4c80b92.I37d68d3f406cb3b90b32e6943418d66070b65197@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: don't get the radio mask for netdev-less wdevs

2026-09-08T11:09:38+00:00

cfg80211_calculate_bi_data() calls rdev_get_radio_mask() with wdev->netdev, which can be NULL and then crashes in mac80211. To avoid that, invert the order of checks since wdev->netdev is always valid for beaconing interfaces. Assisted-by: LLM Fixes: abb4cfe3661a ("wifi: cfg80211: extend interface combination check for multi-radio") Reported-by: syzbot+abff43d2d045e37c0bb2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=abff43d2d045e37c0bb2 Link: https://patch.msgid.link/20260904165614.2056a8b7dc91.I7412c5062d8166ad6c81ee7252cec49dea19a60f@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: clarify and tighten key checks

2026-07-21T17:18:53+00:00

Currently, we accept per-STA GTK for any interface type if the IBSS_RSN flag is set, which doesn't make sense, and also accept various key indices that aren't really (meant to be) supported, such as IGTK/BIGTK on IBSS or AP_VLAN etc. For MESH and NAN_DATA interface types, per-STA GTKs are required, so their support shouldn't depend on IBSS_RSN. Conversely a driver setting IBSS_RSN doesn't really say it also accepts per-STA GTK for other interface types. Move more checks into cfg80211_valid_key_idx() and make them more precise: - allow IGTK and, if supported, BIGTK for NAN - allow per-STA (RX) GTK only for - NAN_DATA - IBSS if IBSS_RSN is supported - MESH - allow B/I/GTK for station/P2P-client without mac_addr for RX with the current AP (historic API quirk), subject to support - allow TX GTK for AP/P2P-GO/AP_VLAN - allow TX IGTK/BIGTK for AP/P2P-GO subject to support Other settings are rejected, clearing up corner cases and disallowing unexpected settings. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715212403.725e6b63e890.I24684374112bb94d0633d61ef76ecb8a1517f7f1@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: remove 5/10 MHz channel support

2026-06-03T12:07:05+00:00

Remove WIPHY_FLAG_SUPPORTS_5_10_MHZ and 5/10 MHz channel width support. We contemplated this back in early 2023 and didn't do it yet, but nobody stepped up to maintain it. It's already _mostly_ dead code since it can really only be used for AP and maybe IBSS and monitor, but not on a client since there's no way to scan (and hasn't been in a very long time, if ever), so the only thing that ever could really happen with it was run syzbot and trip over assumptions in the code. Signed-off-by: Johannes Berg Reviewed-by: Lachlan Hodges Link: https://patch.msgid.link/20260529084502.080c5885f0b7.I77cc94485b523c3c006005b9233db13cd4e077b3@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: add LTF keyseed support for secure ranging

2026-05-05T11:52:23+00:00

Currently there is no way to install an LTF key seed that can be used in non-trigger-based (NTB) and trigger-based (TB) FTM ranging to protect NDP frames. Without this, drivers cannot enable PHY-layer security for peer measurement sessions, leaving ranging measurements vulnerable to eavesdropping and manipulation. Introduce NL80211_KEY_LTF_SEED attribute and the dedicated extended feature flag NL80211_EXT_FEATURE_SET_KEY_LTF_SEED to allow drivers to advertise and install LTF key seeds via nl80211. The key seed must be configured beforehand to ensure the peer measurement session is secure. The driver must advertise both NL80211_EXT_FEATURE_SECURE_LTF and NL80211_EXT_FEATURE_SET_KEY_LTF_SEED for the key seed installation to be permitted. The LTF key seed is pairwise key material and must only be used with pairwise key type. Reject attempts to use it with other key types. Signed-off-by: Peddolla Harshavardhan Reddy Link: https://patch.msgid.link/20260420090856.2152905-13-peddolla.reddy@oss.qualcomm.com [fix policy coding style] 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: validate cipher suite for NAN Data keys

2026-04-28T07:31:12+00:00

Per Wi-Fi Aware v4.0 section 7.1.2, NAN Data interfaces shall only use CCMP-128 or GCMP-256 for frame protection. Enforce this in cfg80211_validate_key_settings() by passing the wdev down to it. Signed-off-by: Daniel Gabay Reviewed-by: Ilan Peer Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260415183550.14a422ac52fd.I486ae7188bc60e44503ecccc99af6ae3a31d16b8@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: allow ToDS=0/FromDS=0 data frames on NAN data interfaces

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

According to Wi-Fi Aware (TM) specification Table 3, data frame should have 0 in the FromDS/ToDS fields. Don't drop received frames with 0 FromDS/ToDS if they are received on NAN_DATA interface. While at it, fix a double indent. Signed-off-by: Daniel Gabay Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260108102921.de5f318a790a.Id34dd69552920b579e6881ffd38fa692a491b601@changeid Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260219094725.3846371-5-miriam.rachel.korenblit@intel.com Link: https://patch.msgid.link/20260318123926.206536-8-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg

wifi: cfg80211: add support for NAN data interface

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

This new interface type represents a NAN data interface (NDI). It is used for data communication with NAN peers. Note that the existing NL80211_IFTYPE_NAN interface, which is the NAN Management Interface (NMI), is used for management communication. An NDI interface is started when a new NAN data path is about to be established, and is stopped after the NAN data path is terminated. - An NDI interface can only be started if the NMI is running, and NAN is started. - Before the NMI is stopped, the NDI interfaces will be stopped. Add the new interface type, handle add/remove operations for it, and makes sure of the conditions above. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260219114327.0d681335c2e2.I92973483e927820ae2297853c141842fdb262747@changeid Link: https://patch.msgid.link/20260318123926.206536-4-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg