If the MPTCP socket fallback to TCP before the MP handshake completion,
the IASN remain 0, and the rcv_wnd_sent filed is not explicitly
initialized, just incremented over time with the data transfer.

At disconnect time such value is not cleared. If the next connection falls
back to TCP before the MP handshake completion, the data transfer will
keep incrementing the receive window end sequence starting from the last
value used in the previous connection: the announced window will be
unrelated from the actual receiver buffer size and likely too big.

Address the issue zeroing the field at disconnect time.

Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
Note that sockopt status is not reset (yet); that should not cause
functional issues and mirrors plain TCP behavior.
---
 net/mptcp/protocol.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 17b9a8c13ebf..42cb55a5d617 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3472,6 +3472,7 @@ static int mptcp_disconnect(struct sock *sk, int flags)
 
 	/* for fallback's sake */
 	WRITE_ONCE(msk->ack_seq, 0);
+	atomic64_set(&msk->rcv_wnd_sent, 0);
 
 	WRITE_ONCE(sk->sk_shutdown, 0);
 	sk_error_report(sk);
-- 
2.54.0

Hi Paolo,

On 08/05/2026 11:48, Paolo Abeni wrote:
> If the MPTCP socket fallback to TCP before the MP handshake completion,
> the IASN remain 0, and the rcv_wnd_sent filed is not explicitly
> initialized, just incremented over time with the data transfer.
> 
> At disconnect time such value is not cleared. If the next connection falls
> back to TCP before the MP handshake completion, the data transfer will
> keep incrementing the receive window end sequence starting from the last
> value used in the previous connection: the announced window will be
> unrelated from the actual receiver buffer size and likely too big.
> 
> Address the issue zeroing the field at disconnect time.

Now in our tree:

New patches for t/upstream-net and t/upstream:
- 0f76d24d882c: mptcp: reset rcv wnd on disconnect
- Results: a968ca54c292..112def6c73e7 (export-net)
- Results: 9ec315f69069..3fc124e79727 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/a5f6725b24b3335e9b3126803421c6e917b94f2b/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/a079ed0689463df3c830498b52c92f871c178586/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Hi Paolo,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/25549767770

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/0450a3ec6b58
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1091536


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Hi Paolo,

On 08/05/2026 11:48, Paolo Abeni wrote:
> If the MPTCP socket fallback to TCP before the MP handshake completion,
> the IASN remain 0, and the rcv_wnd_sent filed is not explicitly
> initialized, just incremented over time with the data transfer.
> 
> At disconnect time such value is not cleared. If the next connection falls
> back to TCP before the MP handshake completion, the data transfer will
> keep incrementing the receive window end sequence starting from the last
> value used in the previous connection: the announced window will be
> unrelated from the actual receiver buffer size and likely too big.
> 
> Address the issue zeroing the field at disconnect time.

Good catch! It looks good to me!

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.