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
next prev parent reply other threads:[~2026-04-12 0:23 UTC|newest]
Thread overview: 3+ 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]
2026-04-17 13:37 ` Forwarded: " syzbot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.