[PATCH mptcp-net] mptcp: reset MP_JOIN subflows on missing or invalid DSS options

[PATCH mptcp-net] mptcp: reset MP_JOIN subflows on missing or invalid DSS options

[T S Rameshkumar]

Per RFC 8684 Section 3.7, fallback to regular TCP is only permitted
on the initial subflow. Additional subflows established via MP_JOIN
MUST NOT fall back to regular TCP, and if an additional subflow
encounters missing DSS mappings, corrupted mappings, or unmapped data,
it MUST be closed with a reset.

Currently, in subflow_check_data_avail(), when an MP_JOIN subflow
receives data without DSS mapping or with invalid mappings, it branches
to the fallback label. If fallback was already performed or allowed on
the connection, the subflow bypasses reset and incorrectly accepts
plain TCP data, synthesizing a fake fallback mapping.

Fix this by explicitly checking if the subflow is a joined subflow
(subflow->mp_join || ssk != READ_ONCE(msk->first)) under the fallback
label. If so, immediately set the appropriate reset reason
(MPTCP_RST_EMIDDLEBOX on MAPPING_NODSS, MPTCP_RST_EMPTCP otherwise),
increment MPTCP_MIB_DSSRESET, and jump to reset.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/544
Signed-off-by: T S Rameshkumar <rameshkumar.t@phytecembedded.in>
---
 net/mptcp/subflow.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 78e886b20..5faab6ffd 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -1446,7 +1446,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
 	return false;
 
 fallback:
-	if (!__mptcp_check_fallback(msk)) {
+	if (subflow->mp_join || ssk != READ_ONCE(msk->first)) {
 		/* RFC 8684 section 3.7. */
 		if (status == MAPPING_BAD_CSUM &&
 		    (subflow->mp_join || subflow->valid_csum_seen)) {
@@ -1461,6 +1461,28 @@ static bool subflow_check_data_avail(struct sock *ssk)
 			return true;
 		}
 
+		subflow->reset_transient = 0;
+		subflow->reset_reason = status == MAPPING_NODSS ?
+					MPTCP_RST_EMIDDLEBOX :
+					MPTCP_RST_EMPTCP;
+		MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSRESET);
+		goto reset;
+	}
+
+	if (!__mptcp_check_fallback(msk)) {
+		/* RFC 8684 section 3.7. */
+		if (status == MAPPING_BAD_CSUM && subflow->valid_csum_seen) {
+			subflow->send_mp_fail = 1;
+
+			if (!mptcp_subflow_fail(msk, ssk)) {
+				subflow->reset_transient = 0;
+				subflow->reset_reason = MPTCP_RST_EMIDDLEBOX;
+				goto reset;
+			}
+			WRITE_ONCE(subflow->data_avail, true);
+			return true;
+		}
+
 		if (!mptcp_try_fallback(ssk, MPTCP_MIB_DSSFALLBACK)) {
 			/* fatal protocol error, close the socket.
 			 * subflow_error_report() will introduce the appropriate barriers
-- 
2.34.1

Re: [PATCH mptcp-net] mptcp: reset MP_JOIN subflows on missing or invalid DSS options

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mptcp: DoS and skipped stats via mptcp_subflow_fail() on MP_JOIN
--

commit 7946d5d8343cbb66aa7761dd1659532067edd960
Author: T S Rameshkumar <rameshsv06@gmail.com>

mptcp: reset MP_JOIN subflows on missing or invalid DSS options

This commit enforces RFC 8684 section 3.7 by explicitly resetting
additional MP_JOIN subflows that encounter missing or invalid DSS
mappings. It prevents these subflows from incorrectly falling back
to regular TCP when fallback is already allowed on the connection.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/544

> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index 2c72cb50fbf36..421832874cc62 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -1446,7 +1446,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
>  	return false;
>  
>  fallback:
> -	if (!__mptcp_check_fallback(msk)) {
> +	if (subflow->mp_join || ssk != READ_ONCE(msk->first)) {
>  		/* RFC 8684 section 3.7. */
>  		if (status == MAPPING_BAD_CSUM &&
>  		    (subflow->mp_join || subflow->valid_csum_seen)) {
>  			subflow->send_mp_fail = 1;
>  
>  			if (!mptcp_subflow_fail(msk, ssk)) {

[Severity: High]
Is it possible to trigger the WARN_ON_ONCE() in mptcp_subflow_fail() when
receiving a bad checksum on an MP_JOIN subflow?

In mptcp_subflow_fail(), we have:

net/mptcp/subflow.c:mptcp_subflow_fail() {
	...
	if (!msk->allow_infinite_fallback) {
		spin_unlock_bh(&msk->fallback_lock);
		return false;
	}
	...
	if (WARN_ON_ONCE(ssk != READ_ONCE(msk->first)))
		return false;
	...
}

Could a remote packet with an invalid checksum on a newly established MP_JOIN
subflow hit this warning before allow_infinite_fallback is set to false?

Looking at mptcp_finish_join() in net/mptcp/protocol.c:

	} else {
		/* defer the graft to the msk lock holder */
		set_bit(MPTCP_WORK_RTX, &msk->flags);
		if (list_empty(&subflow->node))
			list_add_tail(&subflow->node, &msk->join_list);
	}

If the user holds the socket lock (for example, during recvmsg()), the subflow
graft is deferred and msk->allow_infinite_fallback may still be true. During
this window, would a bad checksum packet processed in softirq bypass the early
return in mptcp_subflow_fail(), hit the WARN_ON_ONCE() for the MP_JOIN subflow,
and potentially cause a kernel panic?

>  				subflow->reset_transient = 0;
>  				subflow->reset_reason = MPTCP_RST_EMIDDLEBOX;
>  				goto reset;

[Severity: High]
If mptcp_subflow_fail() returns false and we branch to the reset label here,
doesn't this bypass the MPTCP_MIB_DSSRESET counter increment intended by this
patch?

If msk->allow_infinite_fallback is false, mptcp_subflow_fail() will immediately
return false for an MP_JOIN subflow. Does the resulting goto reset unintentionally
skip over the new MPTCP_INC_STATS(..., MPTCP_MIB_DSSRESET) below?

>  			}
>  			WRITE_ONCE(subflow->data_avail, true);
>  			return true;
>  		}
>  
> +		subflow->reset_transient = 0;
> +		subflow->reset_reason = status == MAPPING_NODSS ?
> +					MPTCP_RST_EMIDDLEBOX :
> +					MPTCP_RST_EMPTCP;
> +		MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSRESET);
> +		goto reset;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012112625.578911-1-rameshkumar.t@phytecembedded.in?part=1

Re: [PATCH mptcp-net] mptcp: reset MP_JOIN subflows on missing or invalid DSS options

[MPTCP CI]

Hi T,

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! ✅
- Perf: Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/38243692179

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


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)

Re: [PATCH mptcp-net] mptcp: reset MP_JOIN subflows on missing or invalid DSS options

[Matthieu Baerts]

Hi T S,

On 12/10/2026 13:26, T S Rameshkumar wrote:
> Per RFC 8684 Section 3.7, fallback to regular TCP is only permitted
> on the initial subflow. Additional subflows established via MP_JOIN
> MUST NOT fall back to regular TCP, and if an additional subflow
> encounters missing DSS mappings, corrupted mappings, or unmapped data,
> it MUST be closed with a reset.
> 
> Currently, in subflow_check_data_avail(), when an MP_JOIN subflow
> receives data without DSS mapping or with invalid mappings, it branches
> to the fallback label. If fallback was already performed or allowed on
> the connection, the subflow bypasses reset and incorrectly accepts
> plain TCP data, synthesizing a fake fallback mapping.

Do you have a reproducer for this?

> Fix this by explicitly checking if the subflow is a joined subflow
> (subflow->mp_join || ssk != READ_ONCE(msk->first)) under the fallback
> label. If so, immediately set the appropriate reset reason
> (MPTCP_RST_EMIDDLEBOX on MAPPING_NODSS, MPTCP_RST_EMPTCP otherwise),
> increment MPTCP_MIB_DSSRESET, and jump to reset.
> 
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/544
> Signed-off-by: T S Rameshkumar <rameshkumar.t@phytecembedded.in>
> ---
>  net/mptcp/subflow.c | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index 78e886b20..5faab6ffd 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -1446,7 +1446,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
>  	return false;
>  
>  fallback:
> -	if (!__mptcp_check_fallback(msk)) {
> +	if (subflow->mp_join || ssk != READ_ONCE(msk->first)) {

Here you are changing the condition "did we already fallback". Is it
because a fallback already happened but yet you have a second subflow?
That's not consistent, and the root cause is elsewhere.

Maybe it is linked to:

https://lore.kernel.org/20260814-mptcp-reset-mpj-early-v1-0-3ca3260f9474@kernel.org

I didn't have time to work on a v2.

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

Re: [PATCH mptcp-net] mptcp: reset MP_JOIN subflows on missing or invalid DSS options

[Matthieu Baerts]

Hi T S,

On 13/10/2026 10:18, T S RAMESHKUMAR wrote:
> Hi Matt,

Please reply in plain text, without HTML. And actually reply to a
message, don't start a new thread when you want to send a reply
otherwise it is not visible when looking at patches:


https://patchwork.kernel.org/project/mptcp/patch/20261012112625.578911-1-rameshkumar.t@phytecembedded.in/

> 1.)  Do you have a reproducer for this?
> 
> No, this was spotted during code review of subflow_check_data_avail()
> rather than from a reproducer in tests or production.

OK. Please mention that in the commit message next time. Or better,
check if this can really happen with a reproducer.

>> Here you are changing the condition "did we already fallback". Is it
>> because a fallback already happened but yet you have a second subflow?
>> That's not consistent, and the root cause is elsewhere.
>> Maybe it is linked to:
>> https://lore.kernel.org/20260814-mptcp-reset-mpj-early-
> v1-0-3ca3260f9474@kernel.org <https://lore.kernel.org/20260814-mptcp-
> reset-mpj-early-v1-0-3ca3260f9474@kernel.org>
>> I didn't have time to work on a v2.
> 
> You are completely right. Once fallback happens on the initial subflow,
> no MP_JOIN subflow should be accepted or established in the first place,
> so patching it under the fallback label in subflow_check_data_avail()
> is indeed only treating a symptom rather than the root cause.

OK, let's drop the patch then.

> I looked at your RFC series (20260814-mptcp-reset-mpj-early-
> v1-0-3ca3260f9474@kernel.org <mailto:20260814-mptcp-reset-mpj-early-
> v1-0-3ca3260f9474@kernel.org>)
> and Paolo's feedback on rejecting MP_JOIN earlier in subflow_check_req().
> If you don't mind, I would be very happy to take over and work on v2
> of that series to address Paolo's comments and get it completed.

Thank you, but I will take the time at some points to send a v2, no
urgency there.

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