[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZInUzhOZ/3TGSQl9@corigine.com>
Date: Wed, 14 Jun 2023 16:55:10 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Jose Abreu <Jose.Abreu@...opsys.com>, stable@...r.kernel.org
Subject: Re: [net PATCH] net: ethernet: stmicro: stmmac: fix possible memory
leak in __stmmac_open
On Wed, Jun 14, 2023 at 09:32:41AM +0200, Christian Marangi wrote:
> Fix a possible memory leak in __stmmac_open when stmmac_init_phy fails.
> It's also needed to free everything allocated by stmmac_setup_dma_desc
> and not just the dma_conf struct.
>
> Correctly call free_dma_desc_resources on the new dma_conf passed to
> __stmmac_open on error.
>
> Reported-by: Jose Abreu <Jose.Abreu@...opsys.com>
> Fixes: ba39b344e924 ("net: ethernet: stmicro: stmmac: generate stmmac dma conf before open")
> Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> Cc: stable@...r.kernel.org
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index fa07b0d50b46..0966ab86fde2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3877,10 +3877,10 @@ static int __stmmac_open(struct net_device *dev,
>
> stmmac_hw_teardown(dev);
> init_error:
> - free_dma_desc_resources(priv, &priv->dma_conf);
> phylink_disconnect_phy(priv->phylink);
> init_phy_error:
> pm_runtime_put(priv->device);
> + free_dma_desc_resources(priv, dma_conf);
Hi Christian,
Are these resources allocated by the caller?
If so, perhaps it would be clearer if a symmetric approach
was taken and the caller handled freeing them on error.
> return ret;
> }
>
> --
> 2.40.1
>
>
Powered by blists - more mailing lists