All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: SHAURYA RANE <ssrane_b23@ee.vjti.ac.in>
Cc: syzbot+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	pabeni@redhat.com, steffen.klassert@secunet.com,
	Edward Adam Davis <eadavis@qq.com>,
	clingfei <clf700383@gmail.com>
Subject: Re: [PATCH] net: key: Validate address family in set_ipsecrequest()
Date: Mon, 27 Oct 2025 20:59:55 +0000	[thread overview]
Message-ID: <20251027205955.GA4074718@horms.kernel.org> (raw)
In-Reply-To: <CANNWa05pX3ratdawb2A6AUBocUgYo+EKZeHBZohQWuBC6_W1AA@mail.gmail.com>

+ clingfei, Edward Adam Davis

On Mon, Oct 20, 2025 at 08:19:50AM +0530, SHAURYA RANE wrote:
> 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>

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] net: key: Validate address family in set_ipsecrequest()
  https://lore.kernel.org/all/CANNWa05pX3ratdawb2A6AUBocUgYo+EKZeHBZohQWuBC6_W1AA@mail.gmail.com/

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

[c] fix integer overflow in set_ipsecrequest
    https://lore.kernel.org/all/20251021030035.1424912-1-1599101385@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!

  parent reply	other threads:[~2025-10-27 20:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20  2:49 [PATCH] net: key: Validate address family in set_ipsecrequest() SHAURYA RANE
2025-10-20  2:52 ` [syzbot] [net?] kernel BUG in set_ipsecrequest syzbot
2025-10-27 20:59 ` Simon Horman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-10-19 18:14 [PATCH] net: key: Validate address family in set_ipsecrequest() ssrane_b23

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251027205955.GA4074718@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=clf700383@gmail.com \
    --cc=eadavis@qq.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ssrane_b23@ee.vjti.ac.in \
    --cc=steffen.klassert@secunet.com \
    --cc=syzbot+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.