Re: [PATCH net-next v2] tcp: honor BPF_SOCK_OPS_RWND_INIT on the active connect path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Incomplete fix for integer overflow when computing the initial receive window in tcp_select_initial_window().
--

--- Patch [1]: [PATCH net-next v2] tcp: honor BPF_SOCK_OPS_RWND_INIT on the active connect path ---
commit 49a334daa027598fc715c7e2fdf73a1c1031f8be
Author: Tejas Birajdar <tejasbirajdar@meta.com>
Subject: tcp: honor BPF_SOCK_OPS_RWND_INIT on the active connect path

This commit enables the BPF_SOCK_OPS_RWND_INIT hook to set the initial TCP
receive window on the active connect path, matching the behavior of the
passive listener path. It also attempts to prevent integer overflow by
computing the inflated space in 64-bit arithmetic and clamping to INT_MAX.

> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index d7c1444b5e304..ffa28c98c2118 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
[ ... ]
> @@ -4137,10 +4138,13 @@ static void tcp_connect_init(struct sock *sk)
>  		WRITE_ONCE(tp->window_clamp, tcp_full_space(sk));
>  
>  	rcv_wnd = tcp_rwnd_init_bpf(sk);
> +	full_space = tcp_full_space(sk);
>  	if (rcv_wnd == 0)
>  		rcv_wnd = dst_metric(dst, RTAX_INITRWND);
> +	else if (full_space < (u64)rcv_wnd * tp->advmss)
> +		full_space = min_t(u64, (u64)rcv_wnd * tp->advmss, INT_MAX);
>  
> -	tcp_select_initial_window(sk, tcp_full_space(sk),
> +	tcp_select_initial_window(sk, full_space,
>  				  tp->advmss - (tp->rx_opt.ts_recent_stamp ? tp->tcp_header_len - sizeof(struct tcphdr) : 0),
>  				  &tp->rcv_wnd,
>  				  &tp->window_clamp,

[Severity: Medium]
This is a pre-existing issue, but does the initial receive window calculation
still overflow inside tcp_select_initial_window() despite the u64 promotion
done here?

When a BPF program returns a very large initial receive window value (for
example, > 2941760 when MSS is 1460), the value is passed as the init_rcv_wnd
parameter into tcp_select_initial_window().

Inside net/ipv4/tcp_output.c:tcp_select_initial_window():

    void tcp_select_initial_window(..., __u32 mss, ..., __u32 init_rcv_wnd)
    {
        ...
        if (init_rcv_wnd)
            *rcv_wnd = min(*rcv_wnd, init_rcv_wnd * mss);
        ...
    }

Because both init_rcv_wnd and mss are 32-bit types, does this multiplication
overflow and wrap around to a small value? This collapses the offered initial
receive window and appears to completely bypass the u64 overflow protection
this patch aims to introduce.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723214208.3655474-1-tejasbirajdar@meta.com?part=1