Re: [PATCH bpf v2 1/1] bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie

Eric Dumazet <[email protected]> Tue, 4 Aug 2026 17:01:33 +0200
Newsgroups org.kernel.vger.bpf,org.kernel.vger.netdev
Message-ID <CANn89i+8EawQn7o2uCosBXDy3VR-uTdxYwjvt3NzyTPsBySfCw@mail.gmail.com>
On Tue, Aug 4, 2026 at 4:29=E2=80=AFPM Ren Wei <[email protected]> wrote=
:
>
> From: Luxiao Xu <[email protected]>
>
> bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie accept a socket pointer
> 'sk' with argument type ARG_PTR_TO_BTF_ID_SOCK_COMMON. However, they acce=
ss
> sk->sk_protocol without validating whether 'sk' represents a full socket.
>
> When a BPF program passes a mini-socket (such as struct request_sock or
> struct inet_timewait_sock obtained via bpf_skc_lookup_tcp), sk_protocol
> is located beyond the memory boundary allocated for mini-sockets.
> Directly dereferencing sk->sk_protocol leads to a slab-out-of-bounds
> kernel read.
>
> Fix this issue by checking sk->sk_state !=3D TCP_LISTEN before inspecting
> sk->sk_protocol in both bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie=
.
> Since mini-sockets are never in the TCP_LISTEN state, the condition
> short-circuits and prevents dereferencing fullsock-specific fields.
>
> Fixes: 399040847084 ("bpf: add helper to check for a valid SYN cookie")
> Fixes: 70d66244317e ("bpf: add bpf_tcp_gen_syncookie helper")
> Cc: [email protected]
> Reported-by: Vega <[email protected]>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Luxiao Xu <[email protected]>
> Signed-off-by: Ren Wei <[email protected]>
> ---
>
> changes in v2:
> v1 Link: https://lore.kernel.org/all/ca8d8c570509b02355bb4bd4e56859f3e256=
[email protected]/
> - Check sk_state before sk_protocol instead of adding sk_fullsock() check=
 (Kuniyuki Iwashima)
> - Correct Fixes tags to point to 399040847084 and 70d66244317e (CI bot)

OK but I do not think this needs a series, a huge cover letter, or a
bloated git log.

AI will be able to rebuild a cover letter (of arbitrary length) and a
full repro just by looking at the fix.

Reviewed-by: Eric Dumazet <[email protected]>