[bug report] wifi: ath11k: fix group data packet drops during rekey

[bug report] wifi: ath11k: fix group data packet drops during rekey

[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);
--> 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

Re: [bug report] wifi: ath11k: fix group data packet drops during rekey

[Rameshkumar Sundaram]

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