From: sashiko-bot@kernel.org
To: "Shihuang Liu" <shlomojune6@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v3 1/2] bpf: reject incompatible socket assignments
Date: Wed, 30 Sep 2026 16:54:15 +0000 [thread overview]
Message-ID: <20260930165415.85C361F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260930164020.41006-1-shlomojune6@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: bpf_sk_assign bypasses family check for encapsulated packets
--
commit bd75dbe60b27d785e5799901fce33eb038028e20
Author: Shihuang Liu <shlomojune6@gmail.com>
bpf: reject incompatible socket assignments
This commit fixes an out-of-bounds stack buffer copy by validating socket
and packet family compatibility in bpf_sk_assign(). It ensures IPv4/IPv6
socket mappings match the packet protocol, maintaining compatibility for
dual-stack and mapped sockets.
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 70dc621672f2e..173349bd2a3f9 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
[ ... ]
> @@ -3491,6 +3491,64 @@ static int bpf_skb_proto_xlat(struct sk_buff *skb, __be16 to_proto)
> return -ENOTSUPP;
> }
>
> +static bool bpf_sk_assign_family_ok_proto(const struct sock *sk, __be16 proto)
> +{
> + const struct inet_connection_sock_af_ops *af_ops;
> + unsigned short family;
> +
> + switch (proto) {
> + case htons(ETH_P_IP):
> + family = AF_INET;
> + break;
> + case htons(ETH_P_IPV6):
> + family = AF_INET6;
> + break;
> + default:
> + return true;
[Severity: High]
Does this default case bypass the family check for encapsulated packets?
If a TC ingress BPF program uses bpf_sk_assign() on an encapsulated packet
(such as MPLS), the switch statement falls through to the default case
and unconditionally returns true because protocols like ETH_P_MPLS_UC are
unrecognized.
If this packet is later decapsulated (e.g., via the TC act_mpls module), its
protocol could change to IPv6 while retaining an assigned AF_INET socket. When
the networking stack processes this decapsulated IPv6 packet with the AF_INET
socket, it may interpret the IPv6 control block data as IPv4 metadata,
leading to an out-of-bounds stack access.
Can this be triggered remotely by sending encapsulated packets, defeating the
vulnerability fix for setups performing decapsulation?
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930164020.41006-1-shlomojune6@gmail.com?part=1
prev parent reply other threads:[~2026-09-30 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 16:40 [PATCH bpf v3 1/2] bpf: reject incompatible socket assignments Shihuang Liu
2026-09-30 16:40 ` [PATCH bpf v3 2/2] bpf: reject incompatible protocol changes Shihuang Liu
2026-09-30 17:26 ` bot+bpf-ci
2026-09-30 16:54 ` sashiko-bot [this message]
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=20260930165415.85C361F00898@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.