From: sashiko-bot@kernel.org
To: "Shihuang Liu" <shlomojune6@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v2 1/2] bpf: reject incompatible socket assignments
Date: Fri, 11 Sep 2026 17:42:58 +0000 [thread overview]
Message-ID: <20260911174258.A064D1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911172313.64009-1-shlomojune6@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The newly added bpf_sk_assign_family_ok() check fails to prevent assigning IPv6 packets to IPv4-mapped AF_INET6 sockets, allowing a bypass that triggers the original stack buffer overflow.
--
commit d0f229f5acd0292d1114ee92bd952f7af2a9e02f
Author: Shihuang Liu <shlomojune6@gmail.com>
Subject: bpf: reject incompatible socket assignments
This commit rejects incompatible packet and socket families in bpf_sk_assign()
and bpf_sk_assign_tcp_reqsk() to prevent a stack buffer overflow. It continues
to allow IPv4 packets to use dual-stack AF_INET6 sockets.
Link: https://lore.kernel.org/netdev/20260823101809.26802-1-shlomojune6@gmail.com/
> diff --git a/net/core/filter.c b/net/core/filter.c
> index cae43b9991627..b5452113f974a 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
[ ... ]
> @@ -3491,6 +3491,32 @@ static int bpf_skb_proto_xlat(struct sk_buff *skb, __be16 to_proto)
[ ... ]
> +static bool bpf_sk_assign_family_ok(const struct sk_buff *skb,
> + const struct sock *sk)
> +{
> + unsigned short family;
> +
> + switch (skb->protocol) {
> + case htons(ETH_P_IP):
> + family = AF_INET;
> + break;
> + case htons(ETH_P_IPV6):
> + family = AF_INET6;
> + break;
> + default:
> + return true;
> + }
> +
> + /* Requests inherit the listener family, but have family-specific ops. */
> + if (sk->sk_state == TCP_NEW_SYN_RECV)
> + return inet_reqsk(sk)->rsk_ops->family == family;
> +
> + return sk->sk_family == family ||
> + (family == AF_INET &&
> + sk->sk_family == AF_INET6 &&
> + !ipv6_only_sock(sk));
> +}
[Severity: Critical]
This is a pre-existing issue, but does this logic still allow a bypass that
triggers the original stack buffer overflow when handling dual-stack AF_INET6
child sockets?
If a dual-stack AF_INET6 listening socket accepts an IPv4 connection, it
creates a child socket with sk_family = AF_INET6 and sk_backlog_rcv =
tcp_v4_do_rcv.
If a malicious IPv6 packet is assigned to this IPv4-mapped child socket using
a TC BPF program, bpf_sk_assign_family_ok() evaluates to true because both the
packet and the socket report AF_INET6, incorrectly allowing the assignment.
If the socket is locked by userspace, the packet gets queued to the backlog.
Upon unlock, release_sock() calls the socket's backlog handler,
tcp_v4_do_rcv(), to process the IPv6 packet.
If tcp_v4_do_rcv() rejects the packet (for example, due to out-of-order data
on a half-closed socket), it jumps to the reset label and calls
tcp_v4_send_reset(), which unconditionally passes the IPv4 options offset to
ip_send_unicast_reply() and __ip_options_echo().
Since the packet was originally processed as IPv6, the control block contains
h6 data instead of IPv4 options. Attacker-controlled IPv6 extension headers
can overlay the IPv4 option offsets, which causes __ip_options_echo() to
execute an out-of-bounds memcpy into a stack buffer.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260911172313.64009-1-shlomojune6@gmail.com?part=1
next prev parent reply other threads:[~2026-09-11 17:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 17:23 [PATCH bpf v2 1/2] bpf: reject incompatible socket assignments Shihuang Liu
2026-09-11 17:23 ` [PATCH bpf v2 2/2] bpf: revalidate assigned sockets after protocol change Shihuang Liu
2026-09-11 17:46 ` sashiko-bot
2026-09-11 17:42 ` sashiko-bot [this message]
2026-09-14 21:55 ` [PATCH bpf v2 1/2] bpf: reject incompatible socket assignments Emil Tsalapatis
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=20260911174258.A064D1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shlomojune6@gmail.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.