[PATCH wireless-next 0/2] wifi: cfg80211/mac80211: indicate (Re)Association frame encryption in SME-in-driver mode

[PATCH wireless-next 0/2] wifi: cfg80211/mac80211: indicate (Re)Association frame encryption in SME-in-driver mode

[Kavita Kavita]

Add support for indicating (Re)Association frame encryption
(IEEE P802.11bi/D4.0, 12.16.6) to userspace (e.g., wpa_supplicant)
in SME-in-driver mode.

These changes are tested with Hwsim Tool.

Kavita Kavita (2):
  wifi: cfg80211: indicate (Re)Association frame encryption to userspace
  wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for
    assoc encryption

 include/net/cfg80211.h       | 6 ++++++
 include/uapi/linux/nl80211.h | 9 +++++++++
 net/mac80211/mlme.c          | 9 +++++++++
 net/wireless/mlme.c          | 1 +
 net/wireless/nl80211.c       | 5 ++++-
 net/wireless/sme.c           | 1 +
 6 files changed, 30 insertions(+), 1 deletion(-)


base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.34.1

[PATCH wireless-next 1/2] wifi: cfg80211: indicate (Re)Association frame encryption to userspace

[Kavita Kavita]

In SME-in-driver mode, the driver handles the entire (re)association
exchange. Userspace (e.g., wpa_supplicant) currently has no explicit
indication of whether the (re)association exchange was encrypted,
making it difficult to distinguish EPP (Enhanced Privacy Protection,
IEEE 802.11bi) associations from non-EPP associations.

When (Re)Association frame encryption is used, the (Re)Association
Response frame must contain a Key Delivery element as specified in
IEEE P802.11bi/D4.0, Table 9-65. Userspace must process this element
only when the (Re)Association Response frame is actually encrypted.
Processing it unconditionally for unencrypted frames leads to incorrect
behavior. Without an explicit indication from the driver, userspace
cannot determine whether encryption was used and whether the Key
Delivery element is valid.

Add a new flag attribute NL80211_ATTR_ASSOC_ENCRYPTED and a
corresponding field "assoc_encrypted" in cfg80211_connect_resp_params.
The driver sets this flag to indicate that the (Re)Association
Request/Response frames are transmitted encrypted over the air.
Pass the flag to userspace via NL80211_CMD_CONNECT event.

Mark NL80211_ATTR_ASSOC_ENCRYPTED with NLA_REJECT in the nl80211
policy to reject any attempt by userspace to send this attribute.

Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
 include/net/cfg80211.h       | 4 ++++
 include/uapi/linux/nl80211.h | 9 +++++++++
 net/wireless/nl80211.c       | 5 ++++-
 net/wireless/sme.c           | 1 +
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9d3639ff9c28..b29fcb4e1a4b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -8835,6 +8835,9 @@ struct cfg80211_fils_resp_params {
  * @links.status: per-link status code, to report a status code that's not
  *	%WLAN_STATUS_SUCCESS for a given link, it must also be in the
  *	@valid_links bitmap and may have a BSS pointer (which is then released)
+ * @assoc_encrypted: The driver should set this flag to indicate that the
+ *	(Re)Association Request/Response frames are transmitted encrypted over
+ *	the air.
  */
 struct cfg80211_connect_resp_params {
 	int status;
@@ -8844,6 +8847,7 @@ struct cfg80211_connect_resp_params {
 	size_t resp_ie_len;
 	struct cfg80211_fils_resp_params fils;
 	enum nl80211_timeout_reason timeout_reason;
+	bool assoc_encrypted;
 
 	const u8 *ap_mld_addr;
 	u16 valid_links;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 3d55bf4be36f..66af29dddb4c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3140,6 +3140,13 @@ enum nl80211_commands {
  *	association response etc., since it's abridged in the beacon. Used
  *	for START_AP etc.
  *
+ * @NL80211_ATTR_ASSOC_ENCRYPTED: Flag attribute, used only with the
+ *	%NL80211_CMD_CONNECT event in SME-in-driver mode. The driver should
+ *	set this flag to indicate that both the (Re)Association Request frame
+ *	and the corresponding (Re)Association Response frame are transmitted
+ *	encrypted over the air. Enhanced Privacy Protection (EPP), as defined
+ *	in IEEE P802.11bi/D4.0, mandates this encryption.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3733,6 +3740,8 @@ enum nl80211_attrs {
 	NL80211_ATTR_NAN_MAX_CHAN_SWITCH_TIME,
 	NL80211_ATTR_NAN_PEER_MAPS,
 
+	NL80211_ATTR_ASSOC_ENCRYPTED,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f334cdef8958..30c737376389 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1076,6 +1076,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
 	[NL80211_ATTR_NAN_MAX_CHAN_SWITCH_TIME] = { .type = NLA_U16 },
 	[NL80211_ATTR_NAN_PEER_MAPS] =
 		NLA_POLICY_NESTED_ARRAY(nl80211_nan_peer_map_policy),
+	[NL80211_ATTR_ASSOC_ENCRYPTED] = { .type = NLA_REJECT },
 };
 
 /* policy for the key attributes */
@@ -20588,7 +20589,9 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
 	      (cr->fils.pmk &&
 	       nla_put(msg, NL80211_ATTR_PMK, cr->fils.pmk_len, cr->fils.pmk)) ||
 	      (cr->fils.pmkid &&
-	       nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))))
+	       nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))) ||
+	    (cr->assoc_encrypted &&
+	     nla_put_flag(msg, NL80211_ATTR_ASSOC_ENCRYPTED)))
 		goto nla_put_failure;
 
 	if (cr->valid_links) {
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 86e2ccaa678c..b451df3096dd 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1066,6 +1066,7 @@ void cfg80211_connect_done(struct net_device *dev,
 	}
 	ev->cr.status = params->status;
 	ev->cr.timeout_reason = params->timeout_reason;
+	ev->cr.assoc_encrypted = params->assoc_encrypted;
 
 	spin_lock_irqsave(&wdev->event_lock, flags);
 	list_add_tail(&ev->list, &wdev->event_list);
-- 
2.34.1

[PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption

[Kavita Kavita]

Extend cfg80211_rx_assoc_resp_data with a new assoc_encrypted field to
indicate if the (re)association exchange is encrypted.

Currently, when epp_peer flag is set, unprotected (Re)Association
Request/Response frames are dropped. This ensures that by the time
the (Re)Association Response is processed, the entire association
exchange is encrypted over the air.

Set assoc_encrypted in cfg80211_rx_assoc_resp_data based on epp_peer
flag when processing the (Re)Association Response.

Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
 include/net/cfg80211.h | 2 ++
 net/mac80211/mlme.c    | 9 +++++++++
 net/wireless/mlme.c    | 1 +
 3 files changed, 12 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b29fcb4e1a4b..f728f565f7e4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -8302,6 +8302,7 @@ void cfg80211_auth_timeout(struct net_device *dev, const u8 *addr);
  *	as the AC bitmap in the QoS info field
  * @req_ies: information elements from the (Re)Association Request frame
  * @req_ies_len: length of req_ies data
+ * @assoc_encrypted: indicate if the (re)association exchange is encrypted.
  * @ap_mld_addr: AP MLD address (in case of MLO)
  * @links: per-link information indexed by link ID, use links[0] for
  *	non-MLO connections
@@ -8316,6 +8317,7 @@ struct cfg80211_rx_assoc_resp_data {
 	const u8 *req_ies;
 	size_t req_ies_len;
 	int uapsd_queues;
+	bool assoc_encrypted;
 	const u8 *ap_mld_addr;
 	struct {
 		u8 addr[ETH_ALEN] __aligned(2);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 160ae65a5c64..3fd98e55d337 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -6658,6 +6658,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
 		.type = le16_to_cpu(mgmt->frame_control) & IEEE80211_FCTL_TYPE,
 	};
 	struct ieee802_11_elems *elems;
+	struct sta_info *sta;
 	int ac;
 	const u8 *elem_start;
 	unsigned int elem_len;
@@ -6853,6 +6854,14 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
 		resp.ap_mld_addr = ap_mld_addr;
 	}
 
+	/*
+	 * If epp_peer set, unprotected (Re)Association Request/Response frames
+	 * are dropped, which ensures that the (re)association exchange is
+	 * encrypted over the air.
+	 */
+	sta = sta_info_get_bss(sdata, sdata->vif.cfg.ap_addr);
+	resp.assoc_encrypted = sta && sta->sta.epp_peer;
+
 	ieee80211_destroy_assoc_data(sdata,
 				     status_code == WLAN_STATUS_SUCCESS ?
 					ASSOC_SUCCESS :
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index bd72317c4964..d196b5c086cc 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -38,6 +38,7 @@ void cfg80211_rx_assoc_resp(struct net_device *dev,
 					u.assoc_resp.variable),
 		.status = le16_to_cpu(mgmt->u.assoc_resp.status_code),
 		.ap_mld_addr = data->ap_mld_addr,
+		.assoc_encrypted = data->assoc_encrypted,
 	};
 	unsigned int link_id;
 
-- 
2.34.1

Re: [PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption

[Johannes Berg]

On Mon, 2026-04-27 at 20:37 +0530, Kavita Kavita wrote:
> Extend cfg80211_rx_assoc_resp_data with a new assoc_encrypted field to
> indicate if the (re)association exchange is encrypted.
> 
> Currently, when epp_peer flag is set, unprotected (Re)Association
> Request/Response frames are dropped. This ensures that by the time
> the (Re)Association Response is processed, the entire association
> exchange is encrypted over the air.
> 
> Set assoc_encrypted in cfg80211_rx_assoc_resp_data based on epp_peer
> flag when processing the (Re)Association Response.

I don't quite see how this is necessary, even in nl80211_send_rx_assoc()
the whole frame, including header and protected bit, is available. Why
does this need mac80211 involvement? One could ask why it's needed *at
all* when userspace already gets the frame and should probably process
the frame RX preferably over the connect result indication...

If this is needed for some reason please outline it in the commit
message, and reshuffle the code to properly split between cfg80211 and
mac80211 in the commits.

johannes

Re: [PATCH wireless-next 1/2] wifi: cfg80211: indicate (Re)Association frame encryption to userspace

[Johannes Berg]

On Mon, 2026-04-27 at 20:37 +0530, Kavita Kavita wrote:
> 
> Mark NL80211_ATTR_ASSOC_ENCRYPTED with NLA_REJECT in the nl80211
> policy to reject any attempt by userspace to send this attribute.

This is not necessary, it's the default given

        [0] = { .strict_start_type = NL80211_ATTR_HE_OBSS_PD },

johannes

Re: [PATCH wireless-next 1/2] wifi: cfg80211: indicate (Re)Association frame encryption to userspace

[Kavita Kavita]

On 4/28/2026 1:09 PM, Johannes Berg wrote:
> On Mon, 2026-04-27 at 20:37 +0530, Kavita Kavita wrote:
>>
>> Mark NL80211_ATTR_ASSOC_ENCRYPTED with NLA_REJECT in the nl80211
>> policy to reject any attempt by userspace to send this attribute.
> 
> This is not necessary, it's the default given
> 
>         [0] = { .strict_start_type = NL80211_ATTR_HE_OBSS_PD },


Agreed, I missed it. I will remove it in the next version. Thank you.


> 
> johannes

Re: [PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption

[Kavita Kavita]

On 4/28/2026 1:08 PM, Johannes Berg wrote:
> On Mon, 2026-04-27 at 20:37 +0530, Kavita Kavita wrote:
>> Extend cfg80211_rx_assoc_resp_data with a new assoc_encrypted field to
>> indicate if the (re)association exchange is encrypted.
>>
>> Currently, when epp_peer flag is set, unprotected (Re)Association
>> Request/Response frames are dropped. This ensures that by the time
>> the (Re)Association Response is processed, the entire association
>> exchange is encrypted over the air.
>>
>> Set assoc_encrypted in cfg80211_rx_assoc_resp_data based on epp_peer
>> flag when processing the (Re)Association Response.
> 
> I don't quite see how this is necessary, even in nl80211_send_rx_assoc()
> the whole frame, including header and protected bit, is available. Why
> does this need mac80211 involvement? One could ask why it's needed *at
> all* when userspace already gets the frame and should probably process
> the frame RX preferably over the connect result indication...
> 



The NL80211_ATTR_ASSOC_ENCRYPTED attribute targets NL80211_CMD_CONNECT, not
NL80211_CMD_ASSOCIATE, both are sent from cfg80211_rx_assoc_resp(), but
NL80211_CMD_CONNECT carries only IEs with no MAC frame headers for either
Request or Response.

The attribute is intended to indicate that the entire exchange was encrypted,
not just the Response. For the Response frame, checking ieee80211_has_protected()
is possible since the full frame is available in data->buf, but for the Request
frame only IEs are stored in ifmgd->assoc_req_ies, the MAC header is not preserved,
so I cannot check the Protected bit for the Request.

While an unencrypted Request paired with an encrypted Response is unlikely in practice,
we did not want to leave that gap, so I used the epp_peer flag. That said, if you think
checking the Protected bit on the Response frame alone is sufficient, we are fine with
that approach too.


> If this is needed for some reason please outline it in the commit
> message, and reshuffle the code to properly split between cfg80211 and
> mac80211 in the commits.



In the wireless-next tip, there are already commits that combine both cfg80211
and mac80211 changes together, so since the assoc_encrypted field addition in
cfg80211 and the mac80211 epp_peer lookup that sets it are tightly dependent on
each other, I kept them in the same commit. If you prefer them split into two
separate commits, I can do that. Will update the commit as well.



> 
> johannes

Re: [PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption

[Kavita Kavita]

On 4/28/2026 1:08 PM, Johannes Berg wrote:
> On Mon, 2026-04-27 at 20:37 +0530, Kavita Kavita wrote:
>> Extend cfg80211_rx_assoc_resp_data with a new assoc_encrypted field to
>> indicate if the (re)association exchange is encrypted.
>>
>> Currently, when epp_peer flag is set, unprotected (Re)Association
>> Request/Response frames are dropped. This ensures that by the time
>> the (Re)Association Response is processed, the entire association
>> exchange is encrypted over the air.
>>
>> Set assoc_encrypted in cfg80211_rx_assoc_resp_data based on epp_peer
>> flag when processing the (Re)Association Response.
> 
> I don't quite see how this is necessary, even in nl80211_send_rx_assoc()
> the whole frame, including header and protected bit, is available. Why
> does this need mac80211 involvement? 

One could ask why it's needed *at
> all* when userspace already gets the frame and should probably process
> the frame RX preferably over the connect result indication...
>



If I correctly understand your point, you meant that when both NL80211_CMD_ASSOCIATE
and NL80211_CMD_CONNECT are indicated (mac80211/SME-in-supplicant case), NL80211_CMD_ASSOCIATE
will always be processed which has the full frame, then the point is valid. However, since
we are sending the NL80211_CMD_CONNECT result, I thought of passing assoc_encrypted there
as well for completeness. At present, there is no use of passing assoc_encrypted in this case,
so we can drop this patch.


 
> If this is needed for some reason please outline it in the commit
> message, and reshuffle the code to properly split between cfg80211 and
> mac80211 in the commits.
> 
> johannes