[PATCH] MLD: Iterate per-link in wpa_clear_keys() for MLO group keys

[Louis Kotze]

When wpa_clear_keys() runs while wpa_s->valid_links is set, the
DEL_KEY loop hardcodes link_id=-1. The kernel cfg80211 validator
nl80211_validate_key_link_id() (introduced in commit e7a7b84e3317
('wifi: cfg80211: Add link_id parameter to various key operations
for MLO'), Linux v6.1+) rejects DEL_KEY for group keys when
wdev->valid_links != 0 and link_id == -1. The DEL_KEYs fail (one
per protected key type: GTK, IGTK, BIGTK), leaving stale per-link
keys in the driver, and the next association is rejected by the
AP with reason 9 (STA_REQ_ASSOC_WITHOUT_AUTH). wpa_supplicant
retries until the SSID is temporarily disabled, then loops on
backoff.

The trigger path is PMKSA-cached reauth on a multi-link AP:
sme_send_authentication() calls wpa_clear_keys() before sending
the fast-reauth association. valid_links is still set from the
prior association at that moment, so every group-key DEL_KEY hits
the validator and fails.

Iterate over wpa_s->valid_links and pass the corresponding
link_id for each active link's group-key DEL_KEY. The non-MLO
path is unchanged.

Tested on a Wi-Fi 7 MLO STA (RTL8922AU + rtw89, kernel 6.19.11,
wpa_supplicant 2.11-9.fc44 patched with this change) against a
TP-Link Deco BE63 mesh: 9 of 9 PMKSA-cached MLO reauth attempts
succeed with the patch applied; the same test on stock 2.11-9
fails intermittently (42 errors observed across 14 retries
during one test session).

A symmetric pattern likely applies to the BIGTK/GTK clearing in
wpa_supplicant_process_1_of_2() (also hardcoded link_id=-1) for
long MLO connections that rekey GTK; it is not exercised by this
particular bug and is not addressed here.

Note: Fedora bug 2458629 listed three commits as candidate fixes:
7a1893fd3aa8 ('MLD: Handle link reconfiguration updates from the
driver'), c7139cc28a07 ('MLD: Clear group keys for removed
links'), and b807ddd8ec7c ('BSS: Set valid_links for all links
and return usable links'). On inspection those touch different
MLO code paths (link reconfig, group-key clearing for removed AP
links, BSS valid_links handling) and do not address the
wpa_clear_keys() / hardcoded link_id=-1 path. wpa_clear_keys() in
master is byte-identical to 2.11 in this respect.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2458629
Signed-off-by: Louis Kotze <loukot at gmail.com>
---
 wpa_supplicant/wpa_supplicant.c | 34 +++++++++++++++++++++++++++------
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 5414eab0f..d8ec85226 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -889,12 +889,34 @@ void wpa_clear_keys(struct wpa_supplicant *wpa_s, const u8 *addr)
 {
 	int i, max = 6;

-	/* MLME-DELETEKEYS.request */
-	for (i = 0; i < max; i++) {
-		if (wpa_s->keys_cleared & BIT(i))
-			continue;
-		wpa_drv_set_key(wpa_s, -1, WPA_ALG_NONE, NULL, i, 0, NULL, 0,
-				NULL, 0, KEY_FLAG_GROUP);
+	/* MLME-DELETEKEYS.request
+	 *
+	 * For MLO connections, group keys are per-link in the kernel and the
+	 * nl80211 validator rejects DEL_KEY for group keys with link_id=-1
+	 * when wdev->valid_links is set. Iterate over each valid link and
+	 * pass the corresponding link_id so the keys are properly cleared.
+	 */
+	if (wpa_s->valid_links) {
+		int link_id;
+
+		for (link_id = 0; link_id < MAX_NUM_MLD_LINKS; link_id++) {
+			if (!(wpa_s->valid_links & BIT(link_id)))
+				continue;
+			for (i = 0; i < max; i++) {
+				if (wpa_s->keys_cleared & BIT(i))
+					continue;
+				wpa_drv_set_key(wpa_s, link_id, WPA_ALG_NONE,
+						NULL, i, 0, NULL, 0,
+						NULL, 0, KEY_FLAG_GROUP);
+			}
+		}
+	} else {
+		for (i = 0; i < max; i++) {
+			if (wpa_s->keys_cleared & BIT(i))
+				continue;
+			wpa_drv_set_key(wpa_s, -1, WPA_ALG_NONE, NULL, i, 0,
+					NULL, 0, NULL, 0, KEY_FLAG_GROUP);
+		}
 	}
 	/* Pairwise Key ID 1 for Extended Key ID is tracked in bit 15 */
 	if (~wpa_s->keys_cleared & (BIT(0) | BIT(15)) && addr &&

base-commit: fd96f14f36939c8f7af7c7592e331e3c10d6efe7
--
2.54.0