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: <20230912180635.GM401982@kernel.org>
Date: Tue, 12 Sep 2023 20:06:35 +0200
From: Simon Horman <horms@...nel.org>
To: Lorenzo Bianconi <lorenzo@...nel.org>
Cc: netdev@...r.kernel.org, lorenzo.bianconi@...hat.com, nbd@....name,
	john@...ozen.org, sean.wang@...iatek.com, Mark-MC.Lee@...iatek.com,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com
Subject: Re: [PATCH net-next] net: ethernet: mtk_wed: do not assume offload
 callbacks are always set

On Tue, Sep 12, 2023 at 10:26:07AM +0200, Lorenzo Bianconi wrote:
> Check if wlan.offload_enable and wlan.offload_disable callbacks are set
> in mtk_wed_flow_add/mtk_wed_flow_remove since mt7996 will not rely
> on them.
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo@...nel.org>

Hi Lorenzo,

It's not not a big deal from my perspective, but
I do wonder if these mediatek patches could have been a series.

> ---
>  drivers/net/ethernet/mediatek/mtk_wed.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_wed.c b/drivers/net/ethernet/mediatek/mtk_wed.c
> index 94376aa2b34c..d8cd59f44401 100644
> --- a/drivers/net/ethernet/mediatek/mtk_wed.c
> +++ b/drivers/net/ethernet/mediatek/mtk_wed.c
> @@ -1718,6 +1718,9 @@ int mtk_wed_flow_add(int index)
>  	if (!hw || !hw->wed_dev)
>  		return -ENODEV;
>  
> +	if (!hw->wed_dev->wlan.offload_enable)
> +		return 0;

A little further down in this function it is assumed that hw->wed_dev may
be NULL, a check made under a lock no less. But it is dereferenced
unconditionally here without a lock. This doesn't seem right one way or
another.

As flagged by Smatch.

> +
>  	if (hw->num_flows) {
>  		hw->num_flows++;
>  		return 0;
> @@ -1747,6 +1750,9 @@ void mtk_wed_flow_remove(int index)
>  	if (!hw)
>  		return;
>  
> +	if (!hw->wed_dev->wlan.offload_disable)
> +		return;
> +
>  	if (--hw->num_flows)
>  		return;
>  
> -- 
> 2.41.0
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ