[PATCH net-next 0/2] tcp: keep the route window on the SYN when SO_RCVBUF is set before connect

[PATCH net-next 0/2] tcp: keep the route window on the SYN when SO_RCVBUF is set before connect

[Shashank Mohan Jain]

v1 was a single [PATCH net] with only the fix. Eric Dumazet pointed out
that the changelog overstated the effect (TCP_WINDOW_CLAMP does not
persist past the first data segments), that "no window scaling" was
inaccurate (the option is still sent, with a shift of 0), and asked for
a packetdrill test and for the series to target net-next. This v2
rewrites the changelog accordingly, leads with the common
SO_RCVBUF-before-connect / listener case, adds a packetdrill test, and
is based on net-next.

Patch 1 is the fix: setsockopt(SO_RCVBUF) must not write tp->window_clamp
while the socket is in TCP_CLOSE or TCP_LISTEN, so that
tcp_connect_init() and tcp_openreq_init_rwin() still apply the route
window metric (RTAX_WINDOW) and the defaults to the SYN / SYN-ACK window
and window scale.

Patch 2 adds a packetdrill test: with "window 4096" on the route to the
peer and SO_RCVBUF set before connect(), the SYN must advertise the
route-clamped window and window scale 0. On an unpatched net-next kernel
the SYN carries win 65535, wscale 5; with patch 1 it carries win 2920,
wscale 0.

Changes since v1 (single [PATCH net]):
 - changelog: say the patch restores the SYN/SYN-ACK window and window
   scale, not a persistent clamp; note that since a2cbb1603943
   tcp_measure_rcv_mss() recomputes window_clamp from sk_rcvbuf anyway.
 - changelog: "wscale 0 (option still sent, shift 0)" instead of "no
   window scaling"; lead with the SO_RCVBUF-before-connect / listener
   case.
 - add the packetdrill selftest (patch 2).
 - retarget from net to net-next.

Shashank Mohan Jain (2):
  tcp: don't set window_clamp from SO_RCVBUF before the socket is
    connected
  selftests/net/packetdrill: test SO_RCVBUF before connect keeps route
    window

 net/ipv4/tcp.c                                |  8 ++++++
 .../tcp_rcvbuf_before_connect_window.pkt      | 27 +++++++++++++++++++
 2 files changed, 35 insertions(+)
 create mode 100644 tools/testing/selftests/net/packetdrill/tcp_rcvbuf_before_connect_window.pkt


base-commit: d8674294aefef02266c4d47ad10131f1bffbe534
-- 
2.43.0

[PATCH net-next 1/2] tcp: don't set window_clamp from SO_RCVBUF before the socket is connected

[Shashank Mohan Jain]

Since commit b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is
set"), setsockopt(SO_RCVBUF) stores tp->window_clamp in every socket
state, including TCP_CLOSE and TCP_LISTEN.

tcp_connect_init() and tcp_openreq_init_rwin() treat a non-zero
window_clamp as a user clamp and, in that case, skip the route window
metric (RTAX_WINDOW, "ip route ... window N"). A clamp left behind by an
SO_RCVBUF call made before connect(), or on a listener, therefore
changes the window and window scale advertised in the SYN and SYN-ACK:
the route metric is no longer applied, and even without a route metric
the advertised window and scale come from SO_RCVBUF instead of the
defaults. This affects any application that sets SO_RCVBUF before
connect() or listen(), which is more common than using the route metric.

Example: two netns joined by a veth pair, "ip route ... window 4096" on
both sides, SO_RCVBUF set to 1 MiB before connect():

  before:  SYN win 65535, wscale 5
  after:   SYN win 2920,  wscale 0

wscale 0 means the window scale option is still sent, with a shift of 0.
The "after" values match a kernel with b025461303d8 reverted; with no
route metric the SYN window and scale are the defaults in both cases.

This only concerns the handshake. Since commit a2cbb1603943 ("tcp:
Update window clamping condition") tcp_measure_rcv_mss() recomputes
window_clamp from sk_rcvbuf once the scaling ratio changes, so
TCP_WINDOW_CLAMP does not persist past the first data segments, with or
without this patch.

Only update window_clamp from SO_RCVBUF once the socket is being set up:
skip it in TCP_CLOSE and TCP_LISTEN. When the connection is established
with SOCK_RCVBUF_LOCK set, both functions already clamp window_clamp to
tcp_full_space() (the value tcp_set_rcvbuf() computes), so nothing is
lost.

Fixes: b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is set")
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
---
 net/ipv4/tcp.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index f4c9101e5..e523cb71b 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1858,6 +1858,14 @@ int tcp_set_rcvlowat(struct sock *sk, int val)
 
 void tcp_set_rcvbuf(struct sock *sk, int val)
 {
+	/* Without a connection there is no clamp to update: it is chosen
+	 * from the route's window metric and the buffer size when the
+	 * connection is set up, see tcp_connect_init() and
+	 * tcp_openreq_init_rwin().
+	 */
+	if ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))
+		return;
+
 	tcp_set_window_clamp(sk, tcp_win_from_space(sk, val));
 }
 
-- 
2.43.0

[PATCH net-next 2/2] selftests/net/packetdrill: test SO_RCVBUF before connect keeps route window

[Shashank Mohan Jain]

Add a packetdrill test for the SYN window and window scale when
SO_RCVBUF is set before connect() and the route to the peer carries a
"window" metric (RTAX_WINDOW).

The test puts "window 4096" on the route to the peer, sets SO_RCVBUF,
connects, and checks that the SYN advertises the route-clamped window
and a window scale of 0. Without the first patch of this series the SYN
carried win 65535, wscale 5, because setsockopt(SO_RCVBUF) had written
tp->window_clamp while the socket was still in TCP_CLOSE and
tcp_connect_init() then skipped the route metric.

The test is picked up automatically by the packetdrill selftest Makefile
(TEST_PROGS := $(wildcard *.pkt)).

Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
---
 .../tcp_rcvbuf_before_connect_window.pkt      | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 tools/testing/selftests/net/packetdrill/tcp_rcvbuf_before_connect_window.pkt

diff --git a/tools/testing/selftests/net/packetdrill/tcp_rcvbuf_before_connect_window.pkt b/tools/testing/selftests/net/packetdrill/tcp_rcvbuf_before_connect_window.pkt
new file mode 100644
index 000000000..a3557ce80
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_rcvbuf_before_connect_window.pkt
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+// Setting SO_RCVBUF before connect() must not defeat the route "window"
+// metric on the SYN.
+//
+// The route to the peer carries "window 4096" (RTAX_WINDOW). With SO_RCVBUF
+// also set before connect(), the SYN the kernel sends must still advertise
+// the small, route-clamped receive window and a window scale of 0 (the
+// window scale option is sent, with a shift of 0).
+//
+// Since commit b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is
+// set"), setsockopt(SO_RCVBUF) wrote tp->window_clamp while the socket was
+// still in TCP_CLOSE. tcp_connect_init() then treated that as a user clamp
+// and skipped RTAX_WINDOW, so the SYN carried win 65535, wscale 5 instead.
+--ip_version=ipv4
+
+`./defaults.sh
+ip route change 192.0.2.1 via 192.168.0.1 dev tun0 window 4096`
+
+    0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+   +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
+   +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+   +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+
+// The SYN must advertise the route-clamped window and window scale 0.
+   +0 > S 0:0(0) win 2920 <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 0>
+  +.1 < S. 0:0(0) ack 1 win 65535 <mss 1460,nop,wscale 7>
+   +0 > . 1:1(0) ack 1
-- 
2.43.0

Re: [PATCH net-next 0/2] tcp: keep the route window on the SYN when SO_RCVBUF is set before connect

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net-next 0/2] tcp: keep the route window on the SYN when SO_RCVBUF is set before connect

[shashank Jain]

On Sun, Oct 11, 2026, netdev-bot+sinfo@kernel.org wrote:
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>  - How the issue was discovered ...

Found by manual code inspection assisted by an LLM (Claude Code, Claude
Opus) while reviewing the networking changes that set window_clamp on
unconnected sockets, then confirmed before posting with the packetdrill
test included as patch 2/2 and a veth/netns reproducer. The patches
carry an "Assisted-by: LLM" tag for that reason.

Thanks,
Shashank

On Sun, Oct 11, 2026 at 4:49 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Re: [PATCH net-next 0/2] tcp: keep the route window on the SYN when SO_RCVBUF is set before connect

[Shashank Mohan Jain]

On Sun, Oct 11, 2026, netdev-bot+sinfo@kernel.org wrote:
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>  - How the issue was discovered ...

Found by manual code inspection assisted by an LLM (Claude Code, Claude
Opus) while reviewing the networking changes that set window_clamp on
unconnected sockets, then confirmed before posting with the packetdrill
test included as patch 2/2 and a veth/netns reproducer. The patches
carry an "Assisted-by: LLM" tag for that reason.

Thanks,
Shashank