netdev - Re: [PATCH ipsec 2/2] espintcp: remove encap socket caching to avoid reference leak

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: <20250411135904.GG395307@horms.kernel.org>
Date: Fri, 11 Apr 2025 14:59:04 +0100
From: Simon Horman <horms@...nel.org>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Herbert Xu <herbert@...dor.apana.org.au>,
	Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [PATCH ipsec 2/2] espintcp: remove encap socket caching to avoid
 reference leak

On Wed, Apr 09, 2025 at 03:59:57PM +0200, Sabrina Dubroca wrote:
> The current scheme for caching the encap socket can lead to reference
> leaks when we try to delete the netns.
> 
> The reference chain is: xfrm_state -> enacp_sk -> netns
> 
> Since the encap socket is a userspace socket, it holds a reference on
> the netns. If we delete the espintcp state (through flush or
> individual delete) before removing the netns, the reference on the
> socket is dropped and the netns is correctly deleted. Otherwise, the
> netns may not be reachable anymore (if all processes within the ns
> have terminated), so we cannot delete the xfrm state to drop its
> reference on the socket.
> 
> This patch results in a small (~2% in my tests) performance
> regression.
> 
> A GC-type mechanism could be added for the socket cache, to clear
> references if the state hasn't been used "recently", but it's a lot
> more complex than just not caching the socket.

Less is more :)

> Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
> Signed-off-by: Sabrina Dubroca <sd@...asysnail.net>

Reviewed-by: Simon Horman <horms@...nel.org>