* [bug report] wifi: ath11k: fix group data packet drops during rekey
@ 2025-09-04 9:23 Dan Carpenter
2025-09-18 16:07 ` Rameshkumar Sundaram
0 siblings, 1 reply; 2+ messages in thread
From: Dan Carpenter @ 2025-09-04 9:23 UTC (permalink / raw)
To: Rameshkumar Sundaram; +Cc: linux-wireless, ath11k
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
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [bug report] wifi: ath11k: fix group data packet drops during rekey
2025-09-04 9:23 [bug report] wifi: ath11k: fix group data packet drops during rekey Dan Carpenter
@ 2025-09-18 16:07 ` Rameshkumar Sundaram
0 siblings, 0 replies; 2+ messages in thread
From: Rameshkumar Sundaram @ 2025-09-18 16:07 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless, ath11k
On 9/4/2025 2:53 PM, Dan Carpenter wrote:
> 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;
>
Thanks for reporting this, will send a patch to fix the if() as well as
remove the code that does |= 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
--
Ramesh
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-09-18 16:08 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-04 9:23 [bug report] wifi: ath11k: fix group data packet drops during rekey Dan Carpenter
2025-09-18 16:07 ` Rameshkumar Sundaram
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox