From: syzbot <syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] xfrm: fix memory leak and improper cleanup in xfrm_add_policy()
Date: Sat, 11 Apr 2026 17:23:31 -0700 [thread overview]
Message-ID: <69dae603.a00a0220.475f0.000d.GAE@google.com> (raw)
In-Reply-To: <69d678c4.050a0220.3030df.000a.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] xfrm: fix memory leak and improper cleanup in xfrm_add_policy()
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
When xfrm_policy_insert() fails in xfrm_add_policy(), the error
handling path manually calls xfrm_dev_policy_free(), followed by
security_xfrm_policy_free() and a raw kfree(). This is problematic
for three reasons:
1. xfrm_policy_destroy() already calls xfrm_dev_policy_free()
internally, so the manual call results in a double-free.
2. xfrm_policy_destroy() frees the policy asynchronously via
call_rcu(), which schedules xfrm_policy_destroy_rcu() to call
security_xfrm_policy_free() and kfree(). The manual
security_xfrm_policy_free() call before kfree() races with this
RCU callback, causing another double-free.
3. The raw kfree() is not RCU-safe and may free memory that is still
being accessed by concurrent RCU readers.
Fix this by using xfrm_policy_destroy() as the single, correct
cleanup path, consistent with how xfrm_policy_construct() handles
its own error paths. The walk.dead flag must be set first as
xfrm_policy_destroy() requires it via BUG_ON(!policy->walk.dead).
Reported-by: syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=901d48e0b95aed4a2548
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
net/xfrm/xfrm_user.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index d56450f61669..ae144d1e4a65 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2267,9 +2267,8 @@ static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
if (err) {
xfrm_dev_policy_delete(xp);
- xfrm_dev_policy_free(xp);
- security_xfrm_policy_free(xp->security);
- kfree(xp);
+ xp->walk.dead = 1;
+ xfrm_policy_destroy(xp);
return err;
}
--
2.43.0
prev parent reply other threads:[~2026-04-12 0:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 15:48 [syzbot] [net?] memory leak in xfrm_policy_construct syzbot
2026-04-12 0:23 ` syzbot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69dae603.a00a0220.475f0.000d.GAE@google.com \
--to=syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox