Skip to contentSkip to conversation

wifi: ath11k: fix group data packet drops during rekey

bug report Dan Carpenter 2 participants 2 messages Sep 4, 2025 – Sep 18, 2025 Qualcomm Atheros ATH11K wireless driver

lore
Share & tools
lore
#0 lore raw

Hello Rameshkumar Sundaram,

Commit 97acb0259cc9 ("wifi: ath11k: fix group data packet drops during rekey") from Aug 10, 2025 (linux-next), leads to the following Smatch static checker warning:

	drivers/net/wireless/ath/ath11k/mac.c:4459 ath11k_mac_op_set_key()
	warn: bitwise AND condition is false here

drivers/net/wireless/ath/ath11k/mac.c
4428
4429 /* Allow group key clearing only in AP mode when no stations are
4430 * associated. There is a known race condition in firmware where
4431 * group addressed packets may be dropped if the key is cleared
4432 * and immediately set again during rekey.
4433 *
4434 * During GTK rekey, mac80211 issues a clear key (if the old key
4435 * exists) followed by an install key operation for same key
4436 * index. This causes ath11k to send two WMI commands in quick
4437 * succession: one to clear the old key and another to install the
4438 * new key in the same slot.
4439 *
4440 * Under certain conditions—especially under high load or time
4441 * sensitive scenarios, firmware may process these commands
4442 * asynchronously in a way that firmware assumes the key is
4443 * cleared whereas hardware has a valid key. This inconsistency
4444 * between hardware and firmware leads to group addressed packet
4445 * drops after rekey.
4446 * Only setting the same key again can restore a valid key in
4447 * firmware and allow packets to be transmitted.
4448 *
4449 * There is a use case where an AP can transition from Secure mode
4450 * to open mode without a vdev restart by just deleting all
4451 * associated peers and clearing key, Hence allow clear key for
4452 * that case alone. Mark arvif->reinstall_group_keys in such cases
4453 * and reinstall the same key when the first peer is added,
4454 * allowing firmware to recover from the race if it had occurred.
4455 */
4456
4457 is_ap_with_no_sta = (vif->type == NL80211_IFTYPE_AP &&
4458 !arvif->num_stations);

--> 4459         if ((flags & WMI_KEY_PAIRWISE) || cmd == SET_KEY || is_ap_with_no_sta) {
                              ^^^^^^^^^^^^^^^^

WMI_KEY_PAIRWISE is zero so this is false.

I should probably write a static checker warning for code that does:

	flags |= WMI_KEY_PAIRWISE;

    4460                 ret = ath11k_install_key(arvif, key, cmd, peer_addr, flags);
    4461                 if (ret) {
    4462                         ath11k_warn(ab, "ath11k_install_key failed (%d)\n", ret);

regards,
dan carpenter

#1 lore raw
Quoted 41 lines · Dan Carpenter

Hello Rameshkumar Sundaram,

Commit 97acb0259cc9 ("wifi: ath11k: fix group data packet drops during rekey") from Aug 10, 2025 (linux-next), leads to the following Smatch static checker warning:

	drivers/net/wireless/ath/ath11k/mac.c:4459 ath11k_mac_op_set_key()
	warn: bitwise AND condition is false here

drivers/net/wireless/ath/ath11k/mac.c
4428
4429 /* Allow group key clearing only in AP mode when no stations are
4430 * associated. There is a known race condition in firmware where
4431 * group addressed packets may be dropped if the key is cleared
4432 * and immediately set again during rekey.
4433 *
4434 * During GTK rekey, mac80211 issues a clear key (if the old key
4435 * exists) followed by an install key operation for same key
4436 * index. This causes ath11k to send two WMI commands in quick
4437 * succession: one to clear the old key and another to install the
4438 * new key in the same slot.
4439 *
4440 * Under certain conditions—especially under high load or time
4441 * sensitive scenarios, firmware may process these commands
4442 * asynchronously in a way that firmware assumes the key is
4443 * cleared whereas hardware has a valid key. This inconsistency
4444 * between hardware and firmware leads to group addressed packet
4445 * drops after rekey.
4446 * Only setting the same key again can restore a valid key in
4447 * firmware and allow packets to be transmitted.
4448 *
4449 * There is a use case where an AP can transition from Secure mode
4450 * to open mode without a vdev restart by just deleting all
4451 * associated peers and clearing key, Hence allow clear key for
4452 * that case alone. Mark arvif->reinstall_group_keys in such cases
4453 * and reinstall the same key when the first peer is added,
4454 * allowing firmware to recover from the race if it had occurred.
4455 */
4456
4457 is_ap_with_no_sta = (vif->type == NL80211_IFTYPE_AP &&
4458 !arvif->num_stations);

Quoted 8 lines
--> 4459         if ((flags & WMI_KEY_PAIRWISE) || cmd == SET_KEY || is_ap_with_no_sta) {
                               ^^^^^^^^^^^^^^^^

WMI_KEY_PAIRWISE is zero so this is false.

I should probably write a static checker warning for code that does:

	flags |= WMI_KEY_PAIRWISE;

Thanks for reporting this, will send a patch to fix the if() as well as remove the code that does |= WMI_KEY_PAIRWISE.

Quoted 6 lines
     4460                 ret = ath11k_install_key(arvif, key, cmd, peer_addr, flags);
     4461                 if (ret) {
     4462                         ath11k_warn(ab, "ath11k_install_key failed (%d)\n", ret);

regards,
dan carpenter

--
Ramesh