Re: [PATCH mptcp-next v6 3/7] mptcp: remove CB offset field

[email protected]
Newsgroups dev.linux.lists.mptcp
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect initialization of `subflow->map_subflow_seq` in `mptcp_propagate_state` completely breaks data reception when falling back to TCP.
--

--- Patch [3]: [PATCH mptcp-next v6 3/7] mptcp: remove CB offset field ---
commit 8a2d837eb49f2826870e0f275e0beb7da32784d7
Author: Paolo Abeni <[email protected]>

mptcp: remove CB offset field

This commit replaces the SKB CB offset field with a new socket-level
copied_seq field to track bytes already consumed. Sequence number tracking
is updated to synchronize with IASN, and MPTCP sequence space is initialized
to 0 in fallback mode.

> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index ed3a48cf9c973..6bffa02c69626 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -520,6 +522,13 @@ static void mptcp_propagate_state(struct sock *sk, struct sock *ssk,
>  		WRITE_ONCE(msk->snd_una, subflow->idsn + 1);
>  		WRITE_ONCE(msk->wnd_end, subflow->idsn + 1 + tcp_sk(ssk)->snd_wnd);
>  		subflow_set_remote_key(msk, subflow, mp_opt);
> +	} else {
> +		/* Fallback: initialize sequence space to 0 (no remote key) */
> +		subflow->map_seq = 0;
> +		/* ensure mptcp_subflow_get_map_offset() returns 0 */
> +		subflow->map_subflow_seq = subflow->ssn_offset +
> +					   tcp_sk(ssk)->copied_seq;

[Severity: High]
Does this code incorrectly initialize map_subflow_seq during TCP fallback?

The comment says this should ensure mptcp_subflow_get_map_offset() returns
0, but the offset and copied_seq are added rather than subtracted.

Because mptcp_subflow_get_map_offset() evaluates
copied_seq - ssn_offset - map_subflow_seq, adding the terms here causes the
offset to evaluate to -2 * ISN.

When falling back to standard TCP, this miscalculation will cause incoming
packets to fail sequence bounds checks against msk->ack_seq, resulting in
data reception failures as packets are either dropped or permanently stuck
in the out-of-order queue.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.