[PATCHSET IPSec 0/3] net: key: Fix address family validation and integer overflow in set_ipsecrequest

[PATCHSET IPSec 0/3] net: key: Fix address family validation and integer overflow in set_ipsecrequest

[clingfei]

From: Cheng Lingfei <clf700383@gmail.com>

Hi,

This patchset addresses a security issue in the PF_KEYv2 implementation where
improper address family validation could lead to integer overflows and buffer
calculation errors in the set_ipsecrequest() function.

The core problem stems from two interrelated issues:

1. The `family` parameter in set_ipsecrequest() is declared as u8 but receives
   a 16-bit value, causing truncation of the upper byte.

2. pfkey_sockaddr_len() returns 0 for unsupported address families, but the
   calling code doesn't properly validate this return value before using it in
   size calculations, leading to potential integer overflows.

The patchset is structured as follows:

Patch 1/3: Corrects the type of the family argument from u8 to u16 to prevent
           truncation of 16-bit address family values.

Patch 2/3: Adds proper validation for the return value of pfkey_sockaddr_len()
           to catch unsupported address families early.

Patch 3/3: Enhances the error handling to ensure zero-length allocations are
           properly rejected and adds appropriate error returns.

This series fixes the original issue introduced in:
Fixes: 14ad6ed30a10 ("net: allow small head cache usage with large MAX_SKB_FRAGS values")

This coordinated approach addresses all aspects of the problem discussed in
the recent thread[1, 2] and provides a comprehensive fix for the IPsec subsystem.

[1] https://lore.kernel.org/all/aP_X8sFJKWVycTn0@horms.kernel.org/
[2] https://lore.kernel.org/all/20251027205955.GA4074718@horms.kernel.org/

Thanks to all contributors who identified different facets of this issue.

Best regards.

Edward Adam Davis (1):
  key: No support for family zero

SHAURYA RANE (1):
  net: key: Validate address family in set_ipsecrequest()

clingfei (1):
  fix integer overflow in set_ipsecrequest

 net/key/af_key.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

-- 
2.34.1

[PATCH 1/3] fix integer overflow in set_ipsecrequest

[clingfei]

From: clingfei <clf700383@gmail.com>

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+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Signed-off-by: Cheng Lingfei <clf700383@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..aa4bd29f27ea 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,
+			    u32 reqid, uint16_t family,
 			    const xfrm_address_t *src, const xfrm_address_t *dst)
 {
 	struct sadb_x_ipsecrequest *rq;
-- 
2.34.1

[PATCH 2/3] key: No support for family zero

[clingfei]

From: Edward Adam Davis <eadavis@qq.com>

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+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Signed-off-by: Edward Adam Davis <eadavis@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 aa4bd29f27ea..cfda15a5aa4d 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.34.1

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

[clingfei]

From: SHAURYA RANE <ssrane_b23@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 <ssrane_b23@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+be97dd4da14ae88b6ba4@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 <ssrane_b23@ee.vjti.ac.in>
---
 net/key/af_key.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index cfda15a5aa4d..93c20a31e03d 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3529,7 +3529,11 @@ static int set_ipsecrequest(struct sk_buff *skb,
 	if (!family)
 		return -EINVAL;
 
-	size_req = sizeof(struct sadb_x_ipsecrequest) +
+    /* Reject invalid/unsupported address families */
+    if (!socklen)
+        return -EINVAL;
+
+    size_req = sizeof(struct sadb_x_ipsecrequest) +
 		   pfkey_sockaddr_pair_size(family);
 
 	rq = skb_put_zero(skb, size_req);
-- 
2.34.1

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[syzbot]

Hello,

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

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

Tested on:

commit:         b54a8e13 Merge branch 'bpf-indirect-jumps'
git tree:       bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10dae114580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
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=106ae114580000

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

Re: [PATCH 3/3] net: key: Validate address family in set_ipsecrequest()

[Sabrina Dubroca]

note: There are a few issues with the format of this patch, and the
subject prefix should be "[PATCH ipsec n/3]" for all the patches in
the series. But I'm also not sure if this is the right way to fix this
syzbot report.


2025-11-06, 21:56:58 +0800, clingfei wrote:
> From: SHAURYA RANE <ssrane_b23@ee.vjti.ac.in>


From here:

> 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 <ssrane_b23@ee.vjti.ac.in>
> Date: Sun, 19 Oct 2025 23:18:30 +0530
> Subject: [PATCH] net: key: Validate address family in set_ipsecrequest()

to here should be removed.


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

So the root of the problem is a mismatch between allocation size and
the actual size needed. Unexpected families are not good, sure, but
would not cause a panic if the sizes were handled correctly.

OTOH, for this old code which is being deprecated, maybe it doesn't
matter to fix it "properly". (but see below)


> 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+be97dd4da14ae88b6ba4@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 <ssrane_b23@ee.vjti.ac.in>
> ---
>  net/key/af_key.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index cfda15a5aa4d..93c20a31e03d 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -3529,7 +3529,11 @@ static int set_ipsecrequest(struct sk_buff *skb,
>  	if (!family)
>  		return -EINVAL;
>  
> -	size_req = sizeof(struct sadb_x_ipsecrequest) +
> +    /* Reject invalid/unsupported address families */

Steffen, AFAICT the whole migrate code has no family
validation. Shouldn't we check {old,new}_family to be one of
{AF_INET,AF_INET6} in xfrm_migrate_check? This should take care of the
problems that this series tries to address, and avoid having objects
installed in the kernel with unexpected families (which would match
what validate_tmpl does).


Looking quickly at xfrm_migrate_state_find, it also seems to compare
addresses without checking that both addresses are of the same
family. That seems a bit wrong, but changing the behavior of that old
code is maybe too risky.



> +    if (!socklen)
> +        return -EINVAL;
> +
> +    size_req = sizeof(struct sadb_x_ipsecrequest) +

nit: tabs should be used, not spaces

>  		   pfkey_sockaddr_pair_size(family);
>  
>  	rq = skb_put_zero(skb, size_req);

-- 
Sabrina

Re: [PATCH 3/3] net: key: Validate address family in set_ipsecrequest()

[clingfei]

Sabrina Dubroca <sd@queasysnail.net> 于2025年11月7日周五 01:17写道：
>
> note: There are a few issues with the format of this patch, and the
> subject prefix should be "[PATCH ipsec n/3]" for all the patches in
> the series. But I'm also not sure if this is the right way to fix this
> syzbot report.
>
>
> 2025-11-06, 21:56:58 +0800, clingfei wrote:
> > From: SHAURYA RANE <ssrane_b23@ee.vjti.ac.in>
>
>
> From here:
>
> > 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 <ssrane_b23@ee.vjti.ac.in>
> > Date: Sun, 19 Oct 2025 23:18:30 +0530
> > Subject: [PATCH] net: key: Validate address family in set_ipsecrequest()
>
> to here should be removed.
>

Sorry for the incorrect format of this patch. I will fix it in later patches.

>
> > 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.
>
> So the root of the problem is a mismatch between allocation size and
> the actual size needed. Unexpected families are not good, sure, but
> would not cause a panic if the sizes were handled correctly.
>
> OTOH, for this old code which is being deprecated, maybe it doesn't
> matter to fix it "properly". (but see below)
>

I agree that the root cause of the problem is a mismatch between
 the allocation size and the actual size needed. I'm not familiar with the
kernel network stack, and I'm unsure if unexpected families might cause
other problems. But, regarding this specific issue, avoiding integer overflow
is sufficient to ensure consistency in size allocation and usage.

>
> > 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+be97dd4da14ae88b6ba4@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 <ssrane_b23@ee.vjti.ac.in>
> > ---
> >  net/key/af_key.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/key/af_key.c b/net/key/af_key.c
> > index cfda15a5aa4d..93c20a31e03d 100644
> > --- a/net/key/af_key.c
> > +++ b/net/key/af_key.c
> > @@ -3529,7 +3529,11 @@ static int set_ipsecrequest(struct sk_buff *skb,
> >       if (!family)
> >               return -EINVAL;
> >
> > -     size_req = sizeof(struct sadb_x_ipsecrequest) +
> > +    /* Reject invalid/unsupported address families */
>
> Steffen, AFAICT the whole migrate code has no family
> validation. Shouldn't we check {old,new}_family to be one of
> {AF_INET,AF_INET6} in xfrm_migrate_check? This should take care of the
> problems that this series tries to address, and avoid having objects
> installed in the kernel with unexpected families (which would match
> what validate_tmpl does).
>
>
> Looking quickly at xfrm_migrate_state_find, it also seems to compare
> addresses without checking that both addresses are of the same
> family. That seems a bit wrong, but changing the behavior of that old
> code is maybe too risky.
>
>
>
> > +    if (!socklen)
> > +        return -EINVAL;
> > +
> > +    size_req = sizeof(struct sadb_x_ipsecrequest) +
>
> nit: tabs should be used, not spaces
>
> >                  pfkey_sockaddr_pair_size(family);
> >
> >       rq = skb_put_zero(skb, size_req);
>
> --
> Sabrina

I think the check on socklen is trying to reject unexpected families,
but I am not sure if it is too late, and this check can only take
effect when the
type of family is handled successfully.

Re: [PATCHSET IPSec 0/3] net: key: Fix address family validation and integer overflow in set_ipsecrequest

[Sabrina Dubroca]

2025-11-06, 21:56:55 +0800, clingfei wrote:
> From: Cheng Lingfei <clf700383@gmail.com>
> 
> Hi,
> 
> This patchset addresses a security issue in the PF_KEYv2 implementation where
> improper address family validation could lead to integer overflows and buffer
> calculation errors in the set_ipsecrequest() function.
> 
> The core problem stems from two interrelated issues:
> 
> 1. The `family` parameter in set_ipsecrequest() is declared as u8 but receives
>    a 16-bit value, causing truncation of the upper byte.
> 
> 2. pfkey_sockaddr_len() returns 0 for unsupported address families, but the
>    calling code doesn't properly validate this return value before using it in
>    size calculations, leading to potential integer overflows.
> 
> The patchset is structured as follows:
> 
> Patch 1/3: Corrects the type of the family argument from u8 to u16 to prevent
>            truncation of 16-bit address family values.
> 
> Patch 2/3: Adds proper validation for the return value of pfkey_sockaddr_len()
>            to catch unsupported address families early.
> 
> Patch 3/3: Enhances the error handling to ensure zero-length allocations are
>            properly rejected and adds appropriate error returns.
> 
> This series fixes the original issue introduced in:
> Fixes: 14ad6ed30a10 ("net: allow small head cache usage with large MAX_SKB_FRAGS values")

This doesn't seem right. It looks more like a mismatch between the
size computation done before allocating the skb and the space actually
needed, and commit 14ad6ed30a10 made the pre-existing bug more visible.

-- 
Sabrina

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[syzbot]

Hello,

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

Reported-by: syzbot+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com
Tested-by: syzbot+be97dd4da14ae88b6ba4@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.

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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

[PATCH] Fix integer overflow in set_ipsecrequest()

[clingfei]

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 <clf700383@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+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Signed-off-by: Cheng Lingfei <clf700383@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,
                            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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[clingfei]

syzbot <syzbot+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com>
于2025年10月20日周一 15:36写道：
>
> 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
>

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 <clf700383@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+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Signed-off-by: Cheng Lingfei <clf700383@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,
                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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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=16776b04580000

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[1599101385]

#syz test

From 2edfc8833e43cdf5ccda8bd5be3da5d1bbdc69c6 Mon Sep 17 00:00:00 2001
From: clingfei <1599101385@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+be97dd4da14ae88b6ba4@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[1599101385]

#syz test:
From 2edfc8833e43cdf5ccda8bd5be3da5d1bbdc69c6 Mon Sep 17 00:00:00 2001
From: clingfei <1599101385@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+be97dd4da14ae88b6ba4@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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 <1599101385@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+be97dd4da14ae88b6ba4@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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.

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

[SHAURYA RANE]

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 <ssrane_b23@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+be97dd4da14ae88b6ba4@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 <ssrane_b23@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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=16621492580000

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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] [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+be97dd4da14ae88b6ba4@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 syzkaller@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[syzbot]

syzbot has bisected this issue to:

commit 14ad6ed30a10afbe91b0749d6378285f4225d482
Author: Paolo Abeni <pabeni@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+be97dd4da14ae88b6ba4@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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 <ssrane_b23@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+be97dd4da14ae88b6ba4@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 <ssrane_b23@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

Re: [syzbot] [net?] kernel BUG in set_ipsecrequest

[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