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

Rameshkumar Sundaram <[email protected]>
Newsgroups org.infradead.lists.ath11k,org.kernel.vger.linux-wireless
Message-ID <[email protected]>

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.