[syzbot] [net?] kernel BUG in set_ipsecrequest

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 48a97ffc6c82 bpf: Consistently use bpf_rcu_lock_held() eve..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=144d0734580000
kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f7e5e2580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11ecec58580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/87ffd600eff3/disk-48a97ffc.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/aa84f0e32430/vmlinux-48a97ffc.xz
kernel image: https://storage.googleapis.com/syzbot-assets/16498048e16c/bzImage-48a97ffc.xz

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

skbuff: skb_over_panic: text:ffffffff8a1fdd63 len:392 put:16 head:ffff888073664d00 data:ffff888073664d00 tail:0x188 end:0x180 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:212!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6012 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:212
Code: c7 60 10 6e 8c 48 8b 74 24 08 48 8b 54 24 10 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 55 41 57 41 56 e8 6e 54 f5 ff 48 83 c4 20 90 <0f> 0b cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90003d5eb68 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: bc84b821dc35fd00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000000180 R08: ffffc90003d5e867 R09: 1ffff920007abd0c
R10: dffffc0000000000 R11: fffff520007abd0d R12: ffff8880720b7b50
R13: ffff888073664d00 R14: ffff888073664d00 R15: 0000000000000188
FS: 000055555b9e7500(0000) GS:ffff888125e0c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055555b9e7808 CR3: 000000007ead6000 CR4: 00000000003526f0
Call Trace:
<TASK>
skb_over_panic net/core/skbuff.c:217 [inline]
skb_put+0x159/0x210 net/core/skbuff.c:2583
skb_put_zero include/linux/skbuff.h:2788 [inline]
set_ipsecrequest+0x73/0x680 net/key/af_key.c:3532
pfkey_send_migrate+0x11f2/0x1de0 net/key/af_key.c:3636
km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2838
xfrm_migrate+0x2020/0x2330 net/xfrm/xfrm_policy.c:4698
xfrm_do_migrate+0x796/0x900 net/xfrm/xfrm_user.c:3144
xfrm_user_rcv_msg+0x7a3/0xab0 net/xfrm/xfrm_user.c:3501
netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552
xfrm_netlink_rcv+0x79/0x90 net/xfrm/xfrm_user.c:3523
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0x21c/0x270 net/socket.c:742
____sys_sendmsg+0x505/0x830 net/socket.c:2630
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684
__sys_sendmsg net/socket.c:2716 [inline]
__do_sys_sendmsg net/socket.c:2721 [inline]
__se_sys_sendmsg net/socket.c:2719 [inline]
__x64_sys_sendmsg+0x19b/0x260 net/socket.c:2719
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5fcd58eec9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe59dd1ab8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f5fcd7e5fa0 RCX: 00007f5fcd58eec9
RDX: 0000000000000000 RSI: 0000200000000380 RDI: 0000000000000004
RBP: 00007f5fcd611f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f5fcd7e5fa0 R14: 00007f5fcd7e5fa0 R15: 0000000000000003
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:212
Code: c7 60 10 6e 8c 48 8b 74 24 08 48 8b 54 24 10 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 55 41 57 41 56 e8 6e 54 f5 ff 48 83 c4 20 90 <0f> 0b cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90003d5eb68 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: bc84b821dc35fd00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000000180 R08: ffffc90003d5e867 R09: 1ffff920007abd0c
R10: dffffc0000000000 R11: fffff520007abd0d R12: ffff8880720b7b50
R13: ffff888073664d00 R14: ffff888073664d00 R15: 0000000000000188
FS: 000055555b9e7500(0000) GS:ffff888125e0c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055555b9e7808 CR3: 000000007ead6000 CR4: 00000000003526f0


---
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]

syzbot has bisected this issue to:

commit 14ad6ed30a10afbe91b0749d6378285f4225d482
Author: Paolo Abeni <pab...@redhat.com>
Date: Tue Feb 18 18:29:39 2025 +0000

net: allow small head cache usage with large MAX_SKB_FRAGS values

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=177a35e2580000
start commit: 48a97ffc6c82 bpf: Consistently use bpf_rcu_lock_held() eve..
git tree: bpf-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=14fa35e2580000
console output: https://syzkaller.appspot.com/x/log.txt?x=10fa35e2580000

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f7e5e2580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11ecec58580000

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Fixes: 14ad6ed30a10 ("net: allow small head cache usage with large MAX_SKB_FRAGS values")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Edward Adam Davis]

When setting the extended skb data for sadb_x_ipsecrequest, the requested
extended data size exceeds the allocated skb data length, triggering the
reported bug.

Because family only supports AF_INET and AF_INET6, other values will cause
pfkey_sockaddr_fill() to fail, which in turn causes set_ipsecrequest() to
fail.

Therefore, a workaround is available here: using a family value of 0 to
resolve the issue of excessively large extended data length.

syzbot reported:

kernel BUG at net/core/skbuff.c:212!

Call Trace:

skb_over_panic net/core/skbuff.c:217 [inline]
skb_put+0x159/0x210 net/core/skbuff.c:2583
skb_put_zero include/linux/skbuff.h:2788 [inline]
set_ipsecrequest+0x73/0x680 net/key/af_key.c:3532

Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)")
Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
net/key/af_key.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2ebde0352245..e658c129b38f 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3526,6 +3526,9 @@ static int set_ipsecrequest(struct sk_buff *skb,
int socklen = pfkey_sockaddr_len(family);
int size_req;

+ if (!family)
+ return -EINVAL;
+
size_req = sizeof(struct sadb_x_ipsecrequest) +
pfkey_sockaddr_pair_size(family);

--
2.43.0

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file net/key/af_key.c
patch: **** unexpected end of file in patch



Tested on:

commit: d9043c79 Merge tag 'sched_urgent_for_v6.18_rc2' of git..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

compiler:
patch: https://syzkaller.appspot.com/x/patch.diff?x=17653a14580000

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file net/key/af_key.c
patch: **** unexpected end of file in patch



Tested on:

commit: d9043c79 Merge tag 'sched_urgent_for_v6.18_rc2' of git..

git tree: upstream

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
compiler:

patch: https://syzkaller.appspot.com/x/patch.diff?x=10e21492580000

[syzbot]

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

[syzbot]

For archival purposes, forwarding an incoming command email to
syzkall...@googlegroups.com.

***

Subject: [PATCH] net: key: Validate address family in set_ipsecrequest()
Author: ssran...@ee.vjti.ac.in

Hi syzbot,

Please test the following patch.

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

Thanks,
Shaurya Rane


From 123c5ac9ba261681b58a6217409c94722fde4249 Mon Sep 17 00:00:00 2001
From: Shaurya Rane <ssran...@ee.vjti.ac.in>
Date: Sun, 19 Oct 2025 23:18:30 +0530
Subject: [PATCH] net: key: Validate address family in set_ipsecrequest()

syzbot reported a kernel BUG in set_ipsecrequest() due to an
skb_over_panic when processing XFRM_MSG_MIGRATE messages.

The root cause is that set_ipsecrequest() does not validate the
address family parameter before using it to calculate buffer sizes.
When an unsupported family value (such as 0) is passed,
pfkey_sockaddr_len() returns 0, leading to incorrect size calculations.

In pfkey_send_migrate(), the buffer size is calculated based on
pfkey_sockaddr_pair_size(), which uses pfkey_sockaddr_len(). When
family=0, this returns 0, so only sizeof(struct sadb_x_ipsecrequest)
(16 bytes) is allocated per entry. However, set_ipsecrequest() is
called multiple times in a loop (once for old_family, once for
new_family, for each migration bundle), repeatedly calling skb_put_zero()
with 16 bytes each time.

This causes the tail pointer to exceed the end pointer of the skb,
triggering skb_over_panic:
tail: 0x188 (392 bytes)
end: 0x180 (384 bytes)

Fix this by validating that pfkey_sockaddr_len() returns a non-zero
value before proceeding with buffer operations. This ensures proper
size calculations and prevents buffer overflow. Checking socklen
instead of just family==0 provides comprehensive validation for all
unsupported address families.

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of
endpoint address(es)")

Signed-off-by: Shaurya Rane <ssran...@ee.vjti.ac.in>
---
net/key/af_key.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2ebde0352245..713344c594d4 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3526,6 +3526,10 @@ static int set_ipsecrequest(struct sk_buff *skb,

int socklen = pfkey_sockaddr_len(family);
int size_req;

+ /* Reject invalid/unsupported address families */
+ if (!socklen)

+ return -EINVAL;
+
size_req = sizeof(struct sadb_x_ipsecrequest) +
pfkey_sockaddr_pair_size(family);

--

2.34.1

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file net/key/af_key.c
patch: **** unexpected end of file in patch



Tested on:

commit: 7361c864 selftests/bpf: Fix list_del() in arena list
git tree: bpf-next

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
compiler:

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

[syzbot]

For archival purposes, forwarding an incoming command email to

linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [Testing] net: key: Validate address family in set_ipsecrequest()
Author: ssran...@ee.vjti.ac.in

Please test the following patch.

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

Thanks,
Shaurya Rane

From: ssran...@gmail.com

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in set_ipsecrequest

skbuff: skb_over_panic: text:ffffffff8a205d63 len:392 put:16 head:ffff88805b276a40 data:ffff88805b276a40 tail:0x188 end:0x180 dev:<NULL>
------------[ cut here ]------------

kernel BUG at net/core/skbuff.c:212!

Oops: invalid opcode: 0000 [#1] SMP KASAN PTI

CPU: 0 UID: 0 PID: 6444 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:212

Code: c7 60 0e 6e 8c 48 8b 74 24 08 48 8b 54 24 10 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 55 41 57 41 56 e8 4e 50 f5 ff 48 83 c4 20 90 <0f> 0b cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90003c06b68 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: 05b0c7e83ffe1100

RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000

RBP: 0000000000000180 R08: ffffc90003c06867 R09: 1ffff92000780d0c
R10: dffffc0000000000 R11: fffff52000780d0d R12: ffff888078c92150
R13: ffff88805b276a40 R14: ffff88805b276a40 R15: 0000000000000188
FS: 00007f2bce8166c0(0000) GS:ffff888125d0b000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007f90ed0682d0 CR3: 0000000069384000 CR4: 00000000003526f0
Call Trace:
<TASK>

skb_over_panic net/core/skbuff.c:217 [inline]
skb_put+0x159/0x210 net/core/skbuff.c:2583
skb_put_zero include/linux/skbuff.h:2788 [inline]
set_ipsecrequest+0x73/0x680 net/key/af_key.c:3532

pfkey_send_migrate+0x11f2/0x1de0 net/key/af_key.c:3636
km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2838
xfrm_migrate+0x2020/0x2330 net/xfrm/xfrm_policy.c:4698
xfrm_do_migrate+0x796/0x900 net/xfrm/xfrm_user.c:3144
xfrm_user_rcv_msg+0x7a3/0xab0 net/xfrm/xfrm_user.c:3501
netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552
xfrm_netlink_rcv+0x79/0x90 net/xfrm/xfrm_user.c:3523
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0x21c/0x270 net/socket.c:742
____sys_sendmsg+0x505/0x830 net/socket.c:2630
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684
__sys_sendmsg net/socket.c:2716 [inline]
__do_sys_sendmsg net/socket.c:2721 [inline]
__se_sys_sendmsg net/socket.c:2719 [inline]
__x64_sys_sendmsg+0x19b/0x260 net/socket.c:2719
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7f2bcd98eec9

Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007f2bce816038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f2bcdbe5fa0 RCX: 00007f2bcd98eec9

RDX: 0000000000000000 RSI: 0000200000000380 RDI: 0000000000000004

RBP: 00007f2bcda11f91 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 00007f2bcdbe6038 R14: 00007f2bcdbe5fa0 R15: 00007ffd8b27cbc8

</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:212

Code: c7 60 0e 6e 8c 48 8b 74 24 08 48 8b 54 24 10 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 55 41 57 41 56 e8 4e 50 f5 ff 48 83 c4 20 90 <0f> 0b cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90003c06b68 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: 05b0c7e83ffe1100

RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000

RBP: 0000000000000180 R08: ffffc90003c06867 R09: 1ffff92000780d0c
R10: dffffc0000000000 R11: fffff52000780d0d R12: ffff888078c92150
R13: ffff88805b276a40 R14: ffff88805b276a40 R15: 0000000000000188
FS: 00007f2bce8166c0(0000) GS:ffff888125e0b000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000200000001f40 CR3: 0000000069384000 CR4: 00000000003526f0

Tested on:

commit: 7361c864 selftests/bpf: Fix list_del() in arena list
git tree: bpf-next

console output: https://syzkaller.appspot.com/x/log.txt?x=12e10e7c580000

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Note: no patches were applied.

[syzbot]

> #syz test:

want either no args or 2 args (repo, branch), got 7

> From 2edfc8833e43cdf5ccda8bd5be3da5d1bbdc69c6 Mon Sep 17 00:00:00 2001
> From: clingfei <15991...@qq.com>
> Date: Mon, 20 Oct 2025 13:40:35 +0800
> Subject: [PATCH] fix integer overflow in set_ipsecrequest
> The mp->new_family and mp->old_family is u16, while set_ipsecrequest receives family as uint8_t,
> causing a integer overflow and the later size_req calculation error, which ultimately triggered a
> kernel bug in skb_put.

>
> Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
>

> ---
> net/key/af_key.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index 2ebde0352245..08f4cde01994 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -3518,7 +3518,7 @@ static int set_sadb_kmaddress(struct sk_buff *skb, const struct xfrm_kmaddress *

>
> static int set_ipsecrequest(struct sk_buff *skb,

> uint8_t proto, uint8_t mode, int level,
> - uint32_t reqid, uint8_t family,
> + uint32_t reqid, uint16_t family,
> const xfrm_address_t *src, const xfrm_address_t *dst)
> {
> struct sadb_x_ipsecrequest *rq;
> --
> 2.34.1

[syzbot]

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

***

Subject: [PATCH] Fix integer overflow in set_ipsecrequest()
Author: clf7...@gmail.com

Hi syzbot,

Please test the following patch.

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

Thanks.

From db24f0985600db1f88d5d2b7420f0707d67ea05a Mon Sep 17 00:00:00 2001
From: clingfei <clf7...@gmail.com>
Date: Mon, 20 Oct 2025 13:48:54 +0800
Subject: [PATCH] fix integer overflow in set_ipsecrequest()

syzbot reported a kernel BUG in set_ipsecrequest() due to an skb_over_panic.

The mp->new_family and mp->old_family is u16, while set_ipsecrequest receives
family as uint8_t, causing a integer overflow and the later size_req calculation

error, which exceeds the size used in alloc_skb, and ultimately triggered the

kernel bug in skb_put.

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

Signed-off-by: Cheng Lingfei <clf7...@gmail.com>

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file net/key/af_key.c
patch: **** unexpected end of file in patch

Tested on:

commit: 7361c864 selftests/bpf: Fix list_del() in arena list
git tree: bpf-next

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
compiler:

patch: https://syzkaller.appspot.com/x/patch.diff?x=104b5de2580000

[shaurya]

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

From 123c5ac9ba261681b58a6217409c94722fde4249 Mon Sep 17 00:00:00 2001

From: Shaurya Rane <ssran...@ee.vjti.ac.in>

Date: Sun, 19 Oct 2025 23:18:30 +0530

Subject: [PATCH] net: key: Validate address family in set_ipsecrequest()

syzbot reported a kernel BUG in set_ipsecrequest() due to an

skb_over_panic when processing XFRM_MSG_MIGRATE messages.

The root cause is that set_ipsecrequest() does not validate the

address family parameter before using it to calculate buffer sizes.

When an unsupported family value (such as 0) is passed,

pfkey_sockaddr_len() returns 0, leading to incorrect size calculations.

In pfkey_send_migrate(), the buffer size is calculated based on

pfkey_sockaddr_pair_size(), which uses pfkey_sockaddr_len(). When

family=0, this returns 0, so only sizeof(struct sadb_x_ipsecrequest)

(16 bytes) is allocated per entry. However, set_ipsecrequest() is

called multiple times in a loop (once for old_family, once for

new_family, for each migration bundle), repeatedly calling skb_put_zero()

with 16 bytes each time.

This causes the tail pointer to exceed the end pointer of the skb,

triggering skb_over_panic:

tail: 0x188 (392 bytes)

end: 0x180 (384 bytes)

Fix this by validating that pfkey_sockaddr_len() returns a non-zero

value before proceeding with buffer operations. This ensures proper

size calculations and prevents buffer overflow. Checking socklen

instead of just family==0 provides comprehensive validation for all

unsupported address families.

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com

Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)")

Signed-off-by: Shaurya Rane <ssran...@ee.vjti.ac.in>

---

net/key/af_key.c | 4 ++++

1 file changed, 4 insertions(+)

diff --git a/net/key/af_key.c b/net/key/af_key.c

index 2ebde0352245..713344c594d4 100644

--- a/net/key/af_key.c

+++ b/net/key/af_key.c

@@ -3526,6 +3526,10 @@ static int set_ipsecrequest(struct sk_buff *skb,

[1599101385]

#syz test

From 2edfc8833e43cdf5ccda8bd5be3da5d1bbdc69c6 Mon Sep 17 00:00:00 2001
From: clingfei <15991...@qq.com>
Date: Mon, 20 Oct 2025 13:40:35 +0800

Subject: [PATCH] fix integer overflow in set_ipsecrequest

The mp->new_family and mp->old_family is u16, while set_ipsecrequest receives family as uint8_t, 

causing a integer overflow and the later size_req calculation error, which ultimately triggered a 
kernel bug in skb_put.

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

---

 net/key/af_key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2ebde0352245..08f4cde01994 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3518,7 +3518,7 @@ static int set_sadb_kmaddress(struct sk_buff *skb, const struct xfrm_kmaddress *

 static int set_ipsecrequest(struct sk_buff *skb,

[15991...@qq.com]

[shaurya]

#syz test:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

From 123c5ac9ba261681b58a6217409c94722fde4249 Mon Sep 17 00:00:00 2001

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of
endpoint address(es)")

Signed-off-by: Shaurya Rane <ssran...@ee.vjti.ac.in>
---
 net/key/af_key.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2ebde0352245..713344c594d4 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3526,6 +3526,10 @@ static int set_ipsecrequest(struct sk_buff *skb,

[ssran...@gmail.com]

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

[syzbot]

patch: https://syzkaller.appspot.com/x/patch.diff?x=16776b04580000

[clingfei]

syzbot <syzbot+be97dd...@syzkaller.appspotmail.com>
于2025年10月20日周一 15:36写道：

Hi syzbot,

Please test the following patch.

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

Thanks.

From 6dc2deb09faf7d53707cc9e75e175b09644fd181 Mon Sep 17 00:00:00 2001
From: clingfei <clf7...@gmail.com>
Date: Mon, 20 Oct 2025 13:48:54 +0800

Subject: [PATCH] fix integer overflow in set_ipsecrequest

syzbot reported a kernel BUG in set_ipsecrequest() due to an skb_over_panic.

The mp->new_family and mp->old_family is u16, while set_ipsecrequest receives
family as uint8_t, causing a integer overflow and the later size_req
calculation

error, which exceeds the size used in alloc_skb, and ultimately triggered the
kernel bug in skb_put.

Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

Signed-off-by: Cheng Lingfei <clf7...@gmail.com>

---
net/key/af_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2ebde0352245..08f4cde01994 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c

@@ -3518,7 +3518,7 @@ static int set_sadb_kmaddress(struct sk_buff
*skb, const struct xfrm_kmaddress *

static int set_ipsecrequest(struct sk_buff *skb,

[syzbot]

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

***

Subject: Re: [syzbot] [net?] kernel BUG in set_ipsecrequest
Author: clf7...@gmail.com

syzbot <syzbot+be97dd...@syzkaller.appspotmail.com>
于2025年10月20日周一 15:48写道：

>
> Hello,
>
> syzbot tried to test the proposed patch but the build/boot failed:
>
> failed to apply patch:
> checking file net/key/af_key.c
> patch: **** unexpected end of file in patch
>
>
>
> Tested on:
>
> commit: 7361c864 selftests/bpf: Fix list_del() in arena list
> git tree: bpf-next

> kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
> dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
> compiler:

> patch: https://syzkaller.appspot.com/x/patch.diff?x=16776b04580000

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file net/key/af_key.c
patch: **** unexpected end of file in patch



Tested on:

commit: 7361c864 selftests/bpf: Fix list_del() in arena list
git tree: bpf-next
kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
compiler:

patch: https://syzkaller.appspot.com/x/patch.diff?x=122d3c58580000

[syzbot]

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

***

Subject:

Author: clf7...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

[syzbot]

Hello,

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

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

Tested on:

commit: 7361c864 selftests/bpf: Fix list_del() in arena list
git tree: bpf-next

console output: https://syzkaller.appspot.com/x/log.txt?x=1089f52f980000

kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4

compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=12bf83cd980000

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

[clingfei]

syzbot found that there is a kernel bug in set_ipsecrequest:

The reason is that there is an integer overflow when calling set_ipsecrequest,
causing the result of `pfkey_sockaddr_pair_size(family)` is not consistent with
that used in alloc_skb, thus exceeds the total buffer size and the kernel panic.

This patch has been tested by syzbot and dit not trigger any issue:

>
> Hello,
>
> syzbot has tested the proposed patch and the reproducer did not trigger any issue:
>
> Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
> Tested-by: syzbot+be97dd...@syzkaller.appspotmail.com
>
> Tested on:
>
> commit: 7361c864 selftests/bpf: Fix list_del() in arena list

> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1089f52f980000

> kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
> dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

> patch: https://syzkaller.appspot.com/x/patch.diff?x=12bf83cd980000
>
> Note: testing is done by a robot and is best-effort only.

[Simon Horman]

+ Shaurya Rane and + Edward Adam Davis

On Thu, Oct 23, 2025 at 08:24:51PM +0800, clingfei wrote:
> syzbot found that there is a kernel bug in set_ipsecrequest:
>

> The root cause is that there is an integer overflow when calling set_ipsecrequest,

> causing the result of `pfkey_sockaddr_pair_size(family)` is not consistent with
> that used in alloc_skb, thus exceeds the total buffer size and the kernel panic.
>

> The issue was detected on bpf-next and linux-next, but the mainstream should also
> have this problem.

>
> This patch has been tested by syzbot and dit not trigger any issue:
> >
> > Hello,
> >
> > syzbot has tested the proposed patch and the reproducer did not trigger any issue:
> >
> > Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
> > Tested-by: syzbot+be97dd...@syzkaller.appspotmail.com
> >
> > Tested on:
> >
> > commit: 7361c864 selftests/bpf: Fix list_del() in arena list

> > git tree: bpf-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1089f52f980000

> > kernel config: https://syzkaller.appspot.com/x/.config?x=9ad7b090a18654a7
> > dashboard link: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
> > compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

> > patch: https://syzkaller.appspot.com/x/patch.diff?x=12bf83cd980000
> >
> > Note: testing is done by a robot and is best-effort only.
>
>
> >From 6dc2deb09faf7d53707cc9e75e175b09644fd181 Mon Sep 17 00:00:00 2001

> From: Cheng Lingfei <clf7...@gmail.com>

> Date: Mon, 20 Oct 2025 13:48:54 +0800
> Subject: [PATCH] fix integer overflow in set_ipsecrequest
>
> syzbot reported a kernel BUG in set_ipsecrequest() due to an skb_over_panic.
>
> The mp->new_family and mp->old_family is u16, while set_ipsecrequest receives
> family as uint8_t, causing a integer overflow and the later size_req calculation
> error, which exceeds the size used in alloc_skb, and ultimately triggered the
> kernel bug in skb_put.
>
> Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
> Signed-off-by: Cheng Lingfei <clf7...@gmail.com>

Firstly, this is not the correct way to structure a commit message. Please
look at the example at [1] for an example of a well structure commit
message. And please look over [2] for documentation of how to structure
patch submissions, and [3] for documentation of the Networking subsystem's
processes.

[1] https://lore.kernel.org/all/7c6b33e4d6e6f2831992bb4631595b1...@redhat.com/
[2] https://docs.kernel.org/process/submitting-patches.html#submittingpatches
[3] https://docs.kernel.org/process/maintainer-netdev.html

Next, this patch is for IPsec code, and is a fix, so probably
it should target the ipsec tree. It should apply cleanly to,
and have been tested against that tree. And the target tree
should be noted in the Subject like this:

Subject: [PATCH ipsec] ...

And there should be a fixes tag.
According to the link in the Closes tag that would be

Fixes: 14ad6ed30a10 ("net: allow small head cache usage with large MAX_SKB_FRAGS values")

But that is not obviously correct to me. More on that in a moment.

> ---
> net/key/af_key.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index 2ebde0352245..08f4cde01994 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -3518,7 +3518,7 @@ static int set_sadb_kmaddress(struct sk_buff *skb, const struct xfrm_kmaddress *
>
> static int set_ipsecrequest(struct sk_buff *skb,
> uint8_t proto, uint8_t mode, int level,
> - uint32_t reqid, uint8_t family,
> + uint32_t reqid, uint16_t family,
> const xfrm_address_t *src, const xfrm_address_t *dst)
> {
> struct sadb_x_ipsecrequest *rq;

I agree that it would be better if family was 16-bits rather than 8-bits,
as the value passed is 16 bits, and pfkey_sockaddr_len() expects a 16 bit
argument. But I don't think this is sufficient to fix to the problem.

The lines following the hunk above are:

u8 *sa;

int socklen = pfkey_sockaddr_len(family);
int size_req;

And the implementation of pfkey_sockaddr_len() is as follows:

static inline int pfkey_sockaddr_len(sa_family_t family)
{
switch (family) {
case AF_INET:
return sizeof(struct sockaddr_in);
#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6:
return sizeof(struct sockaddr_in6);
#endif }
return 0;
}

Where AF_INET is 4 and AF_INET6 is 10. Both of which fit in 8 bits.

And 0 should be returned for any other value, including those with
bits in the upper byte of the 16-bit family set.

It seems to me that a combination of your change, and that proposed
by the following patches - which checks for a 0 return value from
set_ipsecrequest() - is needed.

- net: key: Validate address family in set_ipsecrequest()
https://lore.kernel.org/all/CANNWa05pX3ratdawb2A6AUBo...@mail.gmail.com/T/

- key: No support for family zero
https://lore.kernel.org/all/tencent_57525DE2DDF419...@qq.com/

Both of those patches cite the following

Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)")

Which seems correct to me.

[Simon Horman]

+ Shaurya Rane, clingfei

On Sun, Oct 19, 2025 at 10:34:11AM +0800, Edward Adam Davis wrote:
> When setting the extended skb data for sadb_x_ipsecrequest, the requested
> extended data size exceeds the allocated skb data length, triggering the
> reported bug.
>
> Because family only supports AF_INET and AF_INET6, other values will cause
> pfkey_sockaddr_fill() to fail, which in turn causes set_ipsecrequest() to
> fail.
>
> Therefore, a workaround is available here: using a family value of 0 to
> resolve the issue of excessively large extended data length.
>
> syzbot reported:
> kernel BUG at net/core/skbuff.c:212!
> Call Trace:
> skb_over_panic net/core/skbuff.c:217 [inline]
> skb_put+0x159/0x210 net/core/skbuff.c:2583
> skb_put_zero include/linux/skbuff.h:2788 [inline]
> set_ipsecrequest+0x73/0x680 net/key/af_key.c:3532
>
> Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)")
> Reported-by: syzbot+be97dd...@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
> Signed-off-by: Edward Adam Davis <ead...@qq.com>

Hi,

There are several patches relating to this issue. And they seem
to take one of two approaches.

1. As with this patch [a] and [b]: check the return value of
pfkey_sockaddr_len()

2. As in [c]: correct the type of the family argument to set_ipsecrequest()


[a] key: No support for family zero
https://lore.kernel.org/all/tencent_57525DE2DDF419...@qq.com/

[b] net: key: Validate address family in set_ipsecrequest()
https://lore.kernel.org/all/CANNWa05pX3ratdawb2A6AUBo...@mail.gmail.com/

[c] fix integer overflow in set_ipsecrequest
https://lore.kernel.org/all/20251021030035.14...@qq.com/

I would appreciate it if the patch authors could coordinate creating a
patch(set) to address this issue. And look over the more detailed response
I provided to [c].

Thanks!

--
pw-bot: changes-requested