kernel/git/stable/linux.git/net/wireless/nl80211.c, branch master

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

wifi: nl80211: clean up color-change beacon data on errors

2026-08-02T16:23:27+00:00

nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error. Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data. Fixes: dc1e3cb8da8b ("nl80211: MBSSID and EMA support in AP mode") Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260731120244.82628-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg

wifi: nl80211: send frame tx status event only for non-zero cookie

2026-08-02T15:40:08+00:00

The cookie value assigned by cfg80211_assign_cookie() is guaranteed to be non-zero. So the zero cookie value has special use in tx_control_port where userspace can indicate dont_wait_for_ack, ie. not interested in status. The wil6210 driver also uses the zero cookie when wil_cfg80211_mgmt_tx() is invoked from debugfs api the driver provides so the event is also redundant in that scenario. Signed-off-by: Arend van Spriel Link: https://patch.msgid.link/20260731123509.1975281-14-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg

wifi: cfg80211: convert tx_control_port cookie to input parameter

2026-08-02T15:40:08+00:00

The tx_control_port op was excluded from the previous commit because a NULL cookie was affecting different behavior, ie. signalling that no TX status is wanted. Since cfg80211_assign_cookie() guarantees a non-zero value, cookie value 0 can be used instead. So pass 0 when dont_wait_for_ack is set, otherwise pass value returned from cfg80211_assign_cookie() call. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel Link: https://patch.msgid.link/20260731123509.1975281-13-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg

wifi: cfg80211: convert cookie output to input parameter

2026-08-02T15:40:08+00:00

The remain_on_channel, mgmt_tx, and probe_peer ops previously used a u64 *cookie output parameter. Now that cfg80211 pre-assigns the cookie value before invoking drivers, the parameter conveys a value from caller to driver, not the other way around. Convert it to a plain u64 input parameter across the ops struct (cfg80211.h), rdev-ops.h wrappers, nl80211.c/mlme.c call sites, mac80211, and all driver implementations. The tx_control_port op is excluded: its cookie pointer is nullable (passed as NULL when dont_wait_for_ack is set), so the nullable pointer semantics are still required. Internal mac80211 helpers ieee80211_start_roc_work() and ieee80211_attach_ack_skb() still take u64 *cookie because they assign to the pointee; their callers now pass &cookie to take the address of the local value parameter. wil6210's internal wil_p2p_listen() is also updated to take u64 cookie since it is called directly from the remain_on_channel callback. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel Link: https://patch.msgid.link/20260731123509.1975281-12-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg

wifi: cfg80211: pre-assign cookie for driver callbacks

2026-08-02T15:40:06+00:00

Having a single place for cookie assignment and keeping that responsibility in the cfg80211 subsystem is a logical choice as it handles the userspace nl80211 API. add_nan_func already does this: cfg80211 calls cfg80211_assign_cookie() before invoking the driver. Apply the same pattern to remain_on_channel, mgmt_tx, probe_peer and tx_control_port by pre-assigning the cookie in the nl80211 command handlers before the rdev_* call. For tx_control_port the cookie is only pre-assigned when the caller requests an ack (cookie pointer non-NULL). Drivers may still overwrite the value for now; subsequent patches will remove per-driver cookie generation. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel Link: https://patch.msgid.link/20260731123509.1975281-2-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg

Merge tag 'wireless-2026-07-26' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

2026-07-27T23:03:40+00:00

Johannes Berg says: ==================== wireless-next-2026-07-26 Mostly driver changes this time: - new driver mm81x for an S1G device - new driver nxpwifi for NXP devices (mostly forked off from mwifiex) - ath12k: much kernel infrastructure integration work - brcmfmac: DPP support, some Cypress part update - nl80211: per-link statistics support ==================== Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski

wifi: cfg80211: say why the auth/assoc BSS lookup failed

2026-07-22T14:08:51+00:00

The BSS lookup for an authentication or association request can fail for three distinct reasons: cfg80211 has no scan entry at all for the BSSID/channel, an entry exists but is older than IEEE80211_SCAN_RESULT_EXPIRE (and not held), or a fresh entry exists but its use_for flags do not allow this use. All three currently surface as the same generic extack message "Error fetching BSS for link" on the MLO association path, and as a bare -ENOENT with no message at all on the authentication and non-MLO association paths. Since wpa_supplicant logs the extack message verbatim ("nl80211: kernel reports: ..."), that message is often the only diagnostic a user sees when an MLO association degrades to fewer links, and it does not say whether a fresh scan could have helped. In practice the expired case is common for MLO partner links: 6 GHz is passive-scan in many regulatory domains, so the partner-link entry is routinely stale by the time userspace requests the association even though the link is perfectly usable. Let __cfg80211_get_bss() take an optional extack and record, during the same bss_lock walk that fails the lookup, whether any matching entry was rejected for being expired or for not being usable for the requested use, and set a distinct message for each case (and a combined one when different entries were rejected for different reasons). Reorder the checks in the walk so that an entry's identity (type, privacy, channel, BSSID/SSID) is established before the usability checks; this doesn't change which entry is returned since an entry is only used when all checks pass. Also give the -EINVAL paths in nl80211_assoc_bss() proper messages while at it, and keep pointing the bad_attr at the failing link on the MLO path there; the message for that case is already set by the lookup itself. Signed-off-by: Louis Kotze Link: https://patch.msgid.link/20260722070734.3612581-2-loukot@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: include cf1 offset when sending chandef

2026-07-21T21:29:36+00:00

The cf1 offset is not included when sending the chandef leading to incorrect channel resolution in usermode. Include it. Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20260721053958.227853-1-lachlan.hodges@morsemicro.com 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