Re: [PATCH bpf v4 1/2] bpf: tcp: Reject non-TCP skb in bpf_sk_assign_tcp_reqsk()
From: bot+bpf-ci@kernel.org
Date: 2026-03-30 09:00:40
Also in:
bpf, linux-kselftest, lkml
From: bot+bpf-ci@kernel.org
Date: 2026-03-30 09:00:40
Also in:
bpf, linux-kselftest, lkml
diff --git a/net/core/filter.c b/net/core/filter.c index 78b548158fb0..fb975bcce804 100644 --- a/net/core/filter.c +++ b/net/core/filter.c@@ -12248,11 +12248,17 @@ __bpf_kfunc int bpf_sk_assign_tcp_reqsk(struct __sk_buff *s, struct sock *sk, switch (skb->protocol) {
[ ... ]
#if IS_BUILTIN(CONFIG_IPV6) case htons(ETH_P_IPV6): + if (ipv6_hdr(skb)->nexthdr != IPPROTO_TCP) + return -EINVAL; + ops = &tcp6_request_sock_ops;
For IPv6, ipv6_hdr(skb)->nexthdr gives the type of the header immediately following the base IPv6 header. If extension headers are present (hop-by-hop options, routing, etc.), nexthdr would be the extension header type rather than IPPROTO_TCP, even when the packet is a valid TCP segment. Would it be worth using ipv6_find_hdr() here, similar to bpf_update_srh_state() in the same file, to walk past any extension headers? The IPv4 check above is fine since ip_hdr(skb)->protocol always identifies the transport protocol directly. In practice this is very unlikely to matter since TCP SYN packets with IPv6 extension headers are essentially non-existent, but the check as written would reject them. --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23735111188