From: Loic Poulain loic.poulain@oss.qualcomm.com
[ Upstream commit 487e8a8c3421df0af3707e54c7e069f1d89cbda7 ]
It appears that not all hardware/firmware implementations support group key deletion correctly, which can lead to connection hangs and deauthentication following GTK rekeying (delete and install).
To avoid this issue, instead of attempting to delete the key using the special WMI_CIPHER_NONE value, we now replace the key with an invalid (random) value.
This behavior has been observed with WCN39xx chipsets.
Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Reported-by: Alexey Klimov alexey.klimov@linaro.org Closes: https://lore.kernel.org/all/DAWJQ2NIKY28.1XOG35E4A682G@linaro.org Signed-off-by: Loic Poulain loic.poulain@oss.qualcomm.com Reviewed-by: Baochen Qiang baochen.qiang@oss.qualcomm.com Reviewed-by: Vasanthakumar Thiagarajan vasanthakumar.thiagarajan@oss.qualcomm.com Tested-by: Alexey Klimov alexey.klimov@linaro.org # QRB2210 RB1 Link: https://patch.msgid.link/20250902143225.837487-1-loic.poulain@oss.qualcomm.c... Signed-off-by: Jeff Johnson jeff.johnson@oss.qualcomm.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES - `drivers/net/wireless/ath/ath10k/mac.c:298` now replaces a group key that is being disabled with random bytes instead of sending WMI’s “delete” command (`WMI_CIPHER_NONE`). This directly addresses the field-reported hang/deauth issues seen on WCN39xx when mac80211 performs the standard “delete + install” sequence during GTK rekey; those chips simply don’t tolerate the delete command, so the previous logic routinely broke WPA networks. - The intervention is tightly scoped: the new path is gated on `cmd == DISABLE_KEY` and `flags & WMI_KEY_GROUP`, leaving pairwise keys and normal installs untouched, while still issuing the same `ath10k_wmi_vdev_install_key()` call. Complexity stays minimal, which keeps the backport risk low. - Adding `<linux/random.h>` at `drivers/net/wireless/ath/ath10k/mac.c:19` is the only ancillary change, and `get_random_bytes()` is universally available in the older kernels we target. - I did look for side-effects: mutating `key->key` could matter if mac80211 fell back to software crypto immediately after disabling a group key, but that flow is rare (HW needs to have been using the key already) and, in practice, the key is being deleted precisely because it is no longer supposed to be used. Against that minor theoretical risk we have a severe, reproducible loss of connectivity on modern hardware. - Because the patch fixes a user-visible regression without altering ath10k architecture, and its behaviour aligns with what ath11k already does to survive the same firmware quirk, it fits stable-policy criteria and is worth backporting so that WCN39xx users can keep stable kernels connected once GTK rekeys.
drivers/net/wireless/ath/ath10k/mac.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 24dd794e31ea2..154ac7a709824 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -16,6 +16,7 @@ #include <linux/acpi.h> #include <linux/of.h> #include <linux/bitfield.h> +#include <linux/random.h>
#include "hif.h" #include "core.h" @@ -290,8 +291,15 @@ static int ath10k_send_key(struct ath10k_vif *arvif, key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
if (cmd == DISABLE_KEY) { - arg.key_cipher = ar->wmi_key_cipher[WMI_CIPHER_NONE]; - arg.key_data = NULL; + if (flags & WMI_KEY_GROUP) { + /* Not all hardware handles group-key deletion operation + * correctly. Replace the key with a junk value to invalidate it. + */ + get_random_bytes(key->key, key->keylen); + } else { + arg.key_cipher = ar->wmi_key_cipher[WMI_CIPHER_NONE]; + arg.key_data = NULL; + } }
return ath10k_wmi_vdev_install_key(arvif->ar, &arg);