[syzbot] [net?] memory leak in xfrm_policy_construct

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: a0c83177734a Merge tag 'drm-fixes-2026-03-21' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=117d66da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e2bba615ee79faa5
dashboard link: https://syzkaller.appspot.com/bug?extid=901d48e0b95aed4a2548
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a481d6580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1669ccba580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/76025f732b88/disk-a0c83177.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/51c8f0f97de7/vmlinux-a0c83177.xz
kernel image: https://storage.googleapis.com/syzbot-assets/46b7135c73d1/bzImage-a0c83177.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+901d48...@syzkaller.appspotmail.com

2026/03/21 23:24:08 executed programs: 5
BUG: memory leak
unreferenced object 0xffff888125a86c00 (size 1024):
comm "syz.0.17", pid 6082, jiffies 4294946151
hex dump (first 32 bytes):
00 e5 5f 1c 81 88 ff ff 00 00 00 00 00 00 00 00 .._.............
22 01 00 00 00 00 ad de 00 01 00 00 00 00 ad de "...............
backtrace (crc f62518df):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4543 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
__kmalloc_cache_noprof+0x377/0x480 mm/slub.c:5375
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
xfrm_policy_alloc+0x63/0x180 net/xfrm/xfrm_policy.c:432
xfrm_policy_construct+0x30/0x260 net/xfrm/xfrm_user.c:2187
xfrm_add_policy+0x12e/0x390 net/xfrm/xfrm_user.c:2246
xfrm_user_rcv_msg+0x248/0x570 net/xfrm/xfrm_user.c:3507
netlink_rcv_skb+0x89/0x1c0 net/netlink/af_netlink.c:2550
xfrm_netlink_rcv+0x34/0x40 net/xfrm/xfrm_user.c:3529
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x3a1/0x4f0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x335/0x690 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x54a/0x580 net/socket.c:2592
___sys_sendmsg+0x101/0x140 net/socket.c:2646
__sys_sendmsg+0xcd/0x140 net/socket.c:2678
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] xfrm: fix memory leak and improper cleanup in xfrm_add_policy()
Author: karti...@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+901d48...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=901d48e0b95aed4a2548
Signed-off-by: Deepanshu Kartikey <karti...@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

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+901d48...@syzkaller.appspotmail.com
Tested-by: syzbot+901d48...@syzkaller.appspotmail.com

Tested on:

commit: f5459048 Merge tag 'i2c-for-7.0-final' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12b8f302580000

kernel config: https://syzkaller.appspot.com/x/.config?x=e2bba615ee79faa5
dashboard link: https://syzkaller.appspot.com/bug?extid=901d48e0b95aed4a2548
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44

patch: https://syzkaller.appspot.com/x/patch.diff?x=14e2c74e580000

Note: testing is done by a robot and is best-effort only.

[Helen Koike]

Hey all,

I just noticed I couldn't reproduce on 7.0 upstream/master (3cd8b194bf34), and from a bisect I found that commit 83317cce60a0 "xfrm: fix refcount leak in xfrm_migrate_policy_find" fixes this issue. Which is clear by the commit message and I also reverted it on upstream/master and validated it reproduces. So I'm marking it as fixed:

#syz fix: "xfrm: fix refcount leak in xfrm_migrate_policy_find"

[Aleksandr Nogikh]

Hi Helen,

Thanks for looking into the issue!

Nit: it's better to directly Cc original syzbot emails
(syzbot+901d48...@syzkaller.appspotmail.com in this case)
when sending commands to it, otherwise it may not recognize the bug.

#syz fix: xfrm: fix refcount leak in xfrm_migrate_policy_find

--
Aleksandr

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/8b891373-c70d-4fa9-b8b1-8c1fa06e0756n%40googlegroups.com.

[Helen Koike]

Hi Aleksandr,

On 4/17/26 10:37 AM, Aleksandr Nogikh wrote:
> Hi Helen,
>
> Thanks for looking into the issue!
>
> Nit: it's better to directly Cc original syzbot emails
> (syzbot+901d48...@syzkaller.appspotmail.com in this case)
> when sending commands to it, otherwise it may not recognize the bug.

Thanks for the tip, I replied through the google groups link on the
issue, I through that the "Reply all" button would do the trick
(apparently not), lesson learned.

Helen