net/xfrm/xfrm_state.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
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@seu.edu.cn>
---
net/xfrm/xfrm_state.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 341d79ecb5c2..63506152f893 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -599,9 +599,9 @@ static void ___xfrm_state_destroy(struct xfrm_state *x)
x->mode_cbs->destroy_state(x);
hrtimer_cancel(&x->mtimer);
timer_delete_sync(&x->rtimer);
- kfree(x->aead);
- kfree(x->aalg);
- kfree(x->ealg);
+ kfree_sensitive(x->aead);
+ kfree_sensitive(x->aalg);
+ kfree_sensitive(x->ealg);
kfree(x->calg);
kfree(x->encap);
kfree(x->coaddr);
--
2.34.1
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@seu.edu.cn> Applied to ipsec-next, thanks!
© 2016 - 2026 Red Hat, Inc.