linux-kernel - Re: [PATCH] crypto: caam: fix netdev memory leak in dpaa2_caam

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] [day] [month] [year] [list]

Message-ID: <aijerp5ovv7m5mk2xrfn5rjgkufcynu7vikejqityxloeqnreo@jdnoev2yvfvy>
Date: Fri, 16 Jan 2026 03:43:37 -0800
From: Breno Leitao <leitao@...ian.org>
To: "Chang, Jianpeng (CN)" <Jianpeng.Chang.CN@...driver.com>
Cc: horia.geanta@....com, pankaj.gupta@....com, gaurav.jain@....com, 
	herbert@...dor.apana.org.au, davem@...emloft.net, kuba@...nel.org, 
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: caam: fix netdev memory leak in dpaa2_caam_probe

Hello Jianpeng,

On Fri, Jan 16, 2026 at 06:14:37PM +0800, Chang, Jianpeng (CN) wrote:
> On 1/16/2026 5:46 PM, Breno Leitao wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and know the content is safe.
> > 
> > On Fri, Jan 16, 2026 at 09:44:55AM +0800, Jianpeng Chang wrote:
> > > When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in
> > > dpaa2") converted embedded net_device to dynamically allocated pointers,
> > > it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in
> > > dpaa2_dpseci_free() for error paths.
> > > 
> > > This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe
> > > due to DPIO devices not being ready yet. The kernel's deferred probe
> > > mechanism handles the retry successfully, but the netdevs allocated during
> > > the failed probe attempt are never freed, resulting in kmemleak reports
> > > showing multiple leaked netdev-related allocations all traced back to
> > > dpaa2_caam_probe().
> > > 
> > > Fix this by preserving the CPU mask of allocated netdevs during setup and
> > > using it for cleanup in dpaa2_dpseci_free(). This approach ensures that
> > > only the CPUs that actually had netdevs allocated will be cleaned up,
> > > avoiding potential issues with CPU hotplug scenarios.
> > > 
> > > Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2")
> > > Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@...driver.com>
> > > ---
> > >   drivers/crypto/caam/caamalg_qi2.c | 31 ++++++++++++++++---------------
> > >   drivers/crypto/caam/caamalg_qi2.h |  2 ++
> > >   2 files changed, 18 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/crypto/caam/caamalg_qi2.c b/drivers/crypto/caam/caamalg_qi2.c
> > > index 107ccb2ade42..a66c62174a0f 100644
> > > --- a/drivers/crypto/caam/caamalg_qi2.c
> > > +++ b/drivers/crypto/caam/caamalg_qi2.c
> > > @@ -4810,6 +4810,17 @@ static void dpaa2_dpseci_congestion_free(struct dpaa2_caam_priv *priv)
> > >        kfree(priv->cscn_mem);
> > >   }
> > > 
> > > +static void free_dpaa2_pcpu_netdev(struct dpaa2_caam_priv *priv, const cpumask_t *cpus)
> > c> +{
> > > +     struct dpaa2_caam_priv_per_cpu *ppriv;
> > > +     int i;
> > > +
> > > +     for_each_cpu(i, cpus) {
> > > +             ppriv = per_cpu_ptr(priv->ppriv, i);
> > > +             free_netdev(ppriv->net_dev);
> > > +     }
> > > +}
> > 
> > Why is the function being moved here? Please keep code movement separate
> > from functional changes, or at minimum explain why the move is necessary
> > in the commit message.
> Thank you for the feedback.
> 
> I moved the function because I thought reusing existing code would be
> cleaner in dpaa2_dpseci_free. I will add the explain in commit message.
> 
> For future reference, what's the preferred approach when needing to reuse a
> simple function (4-line loop) defined later in the file - forward
> declaration, move it with a separate change or just implement directly?

It is fine to implement directly, but, I am a bit confused with the
solution, let me back up a bit. 

First, it seems the problem is real and thanks for fixing it.

Regarding the solution, I am wondering if it is not simpler to iterate
the priv->num_pairs and kfreeing them in dpaa2_dpseci_free(), similarly
to dpaa2_dpseci_disable().