linux-kernel - Re: [PATCH v2] xfrm: use kfree_sensitive() for SA secret zeroization

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: <aC1r8VfDy2/mlpwf@gauss3.secunet.de>
Date: Wed, 21 May 2025 08:00:17 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Zilin Guan <zilin@....edu.cn>
CC: <herbert@...dor.apana.org.au>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<horms@...nel.org>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<jianhao.xu@....edu.cn>
Subject: Re: [PATCH v2] xfrm: use kfree_sensitive() for SA secret zeroization

On Wed, May 14, 2025 at 08:48:39AM +0000, Zilin Guan wrote:
> High-level copy_to_user_* APIs already redact SA secret fields when
> redaction is enabled, but the state teardown path still freed aead,
> aalg and ealg structs with plain kfree(), which does not clear memory
> before deallocation. This can leave SA keys and other confidential
> data in memory, risking exposure via post-free vulnerabilities.
> 
> Since this path is outside the packet fast path, the cost of zeroization
> is acceptable and prevents any residual key material. This patch
> replaces those kfree() calls unconditionally with kfree_sensitive(),
> which zeroizes the entire buffer before freeing.
> 
> Signed-off-by: Zilin Guan <zilin@....edu.cn>

Applied to ipsec-next, thanks!