linux-kernel - Re: [PATCH v3 7/8] wifi: wfx: allow to send frames during ROC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fe0a827120e25264550798e07627767148182dd4.camel@siemens.com>
Date: Tue, 26 Nov 2024 15:41:36 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "kvalo@...nel.org" <kvalo@...nel.org>, "jerome.pouiller@...abs.com"
	<jerome.pouiller@...abs.com>
CC: "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 7/8] wifi: wfx: allow to send frames during ROC

Hi Jerome,

On Tue, 2024-11-26 at 15:45 +0100, Jérôme Pouiller wrote:
> In wfx_add_interface(), the list of wvif is protected by conf_lock.
> However, wfx_tx_queues_get_skb() is not protected by conf_lock. We
> initialize struct wvif before to add it to the wvif list and we
> consider it is sufficient. However, after reading memory-barriers.txt
> again, it's probably a wrong assumption.
> 
> 
> So, maybe this could fix the issue:
> 
> diff --git i/drivers/net/wireless/silabs/wfx/sta.c w/drivers/net/wireless/silabs/wfx/sta.c
> index a904602f02ce..b22ea4243c0f 100644
> --- i/drivers/net/wireless/silabs/wfx/sta.c
> +++ w/drivers/net/wireless/silabs/wfx/sta.c
> @@ -748,6 +748,7 @@ int wfx_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
> 
>         for (i = 0; i < ARRAY_SIZE(wdev->vif); i++) {
>                 if (!wdev->vif[i]) {
> +                       smp_mb();
>                         wdev->vif[i] = vif;
>                         wvif->id = i;
>                         break;
> 
> 
> However, I am not confident in playing with memory barriers.

yes, I'd consider the whole TX path very racy again VIF add/remove.
But this is a separate topic...

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com