linux-kernel - Re: [PATCH] net/handshake: Fix memory leak in tls_handshake

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: <20251108044751.1229123-1-zilin@seu.edu.cn>
Date: Sat,  8 Nov 2025 04:47:51 +0000
From: Zilin Guan <zilin@....edu.cn>
To: horms@...nel.org
Cc: chuck.lever@...cle.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	jianhao.xu@....edu.cn,
	kernel-tls-handshake@...ts.linux.dev,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	zilin@....edu.cn
Subject: Re: [PATCH] net/handshake: Fix memory leak in tls_handshake_accept()

On Fri, Nov 07, 2025 at 10:17:09AM +0000, Simon Horman wrote:
> On Thu, Nov 06, 2025 at 02:45:11PM +0000, Zilin Guan wrote:
> > In tls_handshake_accept(), a netlink message is allocated using
> > genlmsg_new(). In the error handling path, genlmsg_cancel() is called
> > to cancel the message construction, but the message itself is not freed.
> > This leads to a memory leak.
> > 
> > Fix this by calling nlmsg_free() in the error path after genlmsg_cancel()
> > to release the allocated memory.
> > 
> > Fixes: 2fd5532044a89 ("net/handshake: Add a kernel API for requesting a TLSv1.3 handshake")
> > Signed-off-by: Zilin Guan <zilin@....edu.cn>
> > ---
> >  net/handshake/tlshd.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/net/handshake/tlshd.c b/net/handshake/tlshd.c
> > index 081093dfd553..8f9532a15f43 100644
> > --- a/net/handshake/tlshd.c
> > +++ b/net/handshake/tlshd.c
> > @@ -259,6 +259,7 @@ static int tls_handshake_accept(struct handshake_req *req,
> >  
> >  out_cancel:
> >  	genlmsg_cancel(msg, hdr);
> 
> Hi Zilin Guan,
> 
> I don't think genlmsg_cancel() is necessary if msg is freed on the next line.
> If so, I suggest removing it, and renaming out_cancel accordingly.
>
> > +	nlmsg_free(msg);
> >  out:
> >  	return ret;
> >  }
> > -- 
> > 2.34.1
> > 

Hi Simon,

Thanks for your review.

I followed the pattern I observed in other parts of the kernel, for example,
in cifs_swn_send_register_message() in fs/smb/client/cifs_swn.c, where
genlmsg_cancel() is also called before nlmsg_free() in the error path.

My understanding is that this is the proper way to unwind the message
construction before freeing it.

If you still believe it's unnecessary, I am happy to send a v2 patch
to remove it.

Best regards,
Zilin Guan