kernel/git/stable/linux.git/include/net/cfg80211.h, branch linux-7.2.y

wifi: cfg80211: use wiphy work for socket owner autodisconnect

2026-07-07T07:27:42+00:00

nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev. Fixes: bd2522b16884 ("cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT") Suggested-by: Johannes Berg Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260706152418.779226-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock

2026-07-06T12:11:08+00:00

When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down(). Fixes: 6dccbc9f3e1d ("wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down") Signed-off-by: Peddolla Harshavardhan Reddy Link: https://patch.msgid.link/20260703082523.2629324-1-peddolla.reddy@oss.qualcomm.com Signed-off-by: Johannes Berg

wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer notifications

2026-06-05T08:00:04+00:00

Currently, ie_len in cfg80211_notify_new_peer_candidate is defined as 1-byte field, capping the maximum IE list size at 255 bytes. When a large beacon is received, the IE list is truncated, passing incomplete data to wpa_supplicant. This causes supplicant to fail parsing the IEs. Increasing the size of ie_len to allow the full length of the IE list to be forwarded properly. Signed-off-by: Thiyagarajan Pandiyan Link: https://patch.msgid.link/20260605054307.427874-1-thiyagarajan@aerlync.com 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 a function to parse UHR DBE

2026-05-20T10:03:19+00:00

Add a function that takes the DBE information and parses it into an existing chandef that should hold the BSS channel. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260515141209.4eb1490f5cc6.I3ca9421f1fe4c31073846b1b62017f12c75889de@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: separate NPCA validity from chandef validity

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

When considering both NPCA and DBE, it can appear that the NPCA configuration is invalid, e.g. for an 80 MHz BSS channel with DBE to 160 MHz: | primary channel | NPCA primary channel | | V V | p | | n | | | | | | | BSS channel | | DBE channel | Now the NPCA primary channel is in the same half as the primary channel, and the NPCA puncturing bitmap could be completely invalid as a puncturing bitmap when considering the overall channel. Split out the validity checks from cfg80211_chandef_valid() to a new cfg80211_chandef_npca_valid() function that just checks the NPCA configuration against the BSS chandef. Link: https://patch.msgid.link/20260428112708.1225df131557.If3a6afadcce05d215b72fd82175f72373a0f6d24@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: add helper for parsing NPCA to chandef

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

Add a cfg80211_chandef_add_npca() helper function that takes an existing chandef without NPCA and sets the NPCA information from the format used in UHR operation and UHR Parameters Update. Link: https://patch.msgid.link/20260428112708.5cdc4e69a306.I95d396ac671da438f340b1afb735ebfe33164894@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: allow representing NPCA in chandef

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

Add the necessary fields to the chandef data structure to represent NPCA (the NPCA primary channel and NPCA punctured/disabled subchannels bitmap), and the code to check these for validity, compatibility, as well as allowing it to be passed for AP mode for capable devices. Compatibility is assumed to only be the case when it's actually identical, enabling later management of this in channel contexts in mac80211 for multiple APs, but requiring userspace to set up the identical chandef on all AP interfaces that share a channel (and BSS color.) Link: https://patch.msgid.link/20260428112708.46f3872aeb35.I85888dab88a6659ba52db4b3318979ca5bcfc0c8@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: allow devices to advertise extended MLD capa/ops

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

For UHR, multi-link power-management capability lives there, and so it's needed that hostapd knows what to advertise, and clients should have it shown to userspace for information. Repurpose the existing NL80211_ATTR_ASSOC_MLD_EXT_CAPA_OPS by renaming it to NL80211_ATTR_EXT_MLD_CAPA_AND_OPS (with a define for compatibility) and advertise the capabilities. We can also later use the value, if needed, to set per-station capabilities on STAs added to AP interfaces. Link: https://patch.msgid.link/20260428110915.e808e70feed6.I378a7c017bfc1ebb072fa8d5d1db2ac9b45596c9@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