kernel/git/stable/linux.git/net/mptcp, branch master

mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction

2026-08-20T19:53:14+00:00

mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields. Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") Cc: stable@vger.kernel.org Signed-off-by: Harshit Varu Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260815115205.197151-1-harshitvaru666@gmail.com Signed-off-by: Jakub Kicinski

mptcp: add per-event MIB counters for MPTCP_RST_EMPTCP resets

2026-08-18T00:25:49+00:00

MPTCP_RST_EMPTCP (reset reason 1) is used as a catch-all for several distinct error conditions across subflow setup, authentication, and data-path validation. The existing MPRstTx/MPRstRx counters only track aggregate reset volume, making it difficult to diagnose which code path is triggering subflow resets in production. Add per-event MIB counters covering each MPTCP_RST_EMPTCP use site that is not already covered by an existing counter, named after the underlying event or condition rather than the reset action: MD5SigReset MD5SIG enabled on listener (incompatible) MPJoinSynAckNoMPJoin SYN/ACK missing MP_JOIN option MPJoinAckNoMPJoin server-side ACK missing MP_JOIN option (fallback path, MPJoin required) MPJoinAckNoCtx server-side ACK with no subflow context MPJoinNoIdFound MP_JOIN with a valid token but no PM local ID DssReset data mapping invalid (also fires on MAPPING_NODSS / EMIDDLEBOX path) MPJoinNotEstablished JOIN attempted on a not-fully-established msk MPJoinNoIdFound covers the second half of the no-msk MP_JOIN reset: the existing MPJoinNoTokenFound (MPTCP_MIB_JOINNOTOKEN) only counts the missing-token case in subflow_token_join_request(), while a JOIN that carries a valid token but for which the path manager returns no local id reaches the same MPTCP_RST_EMPTCP in subflow_check_req() uncounted. The aggregate MPRstTx/MPRstRx counters are unchanged. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/511 Signed-off-by: Shardul Bankar Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-5-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski

mptcp: honour configured min/max RTO in retransmit paths

2026-08-18T00:25:49+00:00

The MPTCP-level retransmit timers (DATA_FIN retransmissions and the fallback timeout) used the hard-coded TCP_RTO_MIN / TCP_RTO_MAX constants, ignoring the tcp_rto_min_us and tcp_rto_max_ms sysctls. Make them follow the sysctls instead: seed icsk_rto_min / icsk_rto_max on the MPTCP socket from the per-netns sysctls in __mptcp_init_sock() -- the msk does not go through tcp_init_sock(), so these fields would otherwise stay zero -- and read them directly where the constants were used: - mptcp_set_datafin_timeout(): both the backoff cap computation and the resulting timer_ival. The two sysctls are validated independently, so rto_min > rto_max is a valid configuration; keep a max_t() guard so ilog2() is never called with 0. - __mptcp_set_timeout(): the fallback when no subflow timeout is available. The icsk fields are read directly instead of using the tcp_rto_min()/tcp_rto_max() helpers: the MPTCP socket does not perform routing lookups in these paths, so the rto_min route metric checked by tcp_rto_min() can never apply here. The TCP_RTO_MIN_US / TCP_RTO_MAX_MS socket options are not supported by MPTCP setsockopt() either; this can be revisited if they get supported on MPTCP sockets. The remaining uses of TCP_RTO_MAX in net/mptcp/ctrl.c (default add_addr_timeout) and net/mptcp/subflow.c (MP_FAIL timeout) are intentionally left unchanged: they use the constant as a default duration, not as an RTO bound on a retransmit timer. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/618 Signed-off-by: Kalpan Jani Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-4-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: userspace: make remove_addr_entry static

2026-08-18T00:25:49+00:00

Only used in pm_userspace.c. While at it, use the mptcp_userspace_pm_ prefix, like most functions in this file: that makes it clear it is specific to this userspace PM. Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-3-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: add WARN_ON_ONCE guards on extra_subflows underflow

2026-08-18T00:25:49+00:00

extra_subflows is a u8 counter that can underflow if a decrement races with or precedes an increment. While the recently fixed userspace PM subflow creation path eliminated the primary cause, add defensive WARN_ON_ONCE guards at both decrement sites to catch any remaining edge cases rather than silently wrapping to 255. Signed-off-by: Tao Cui Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-1-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski

mptcp: implemented OoO queue pruning

2026-08-12T01:35:38+00:00

When moving incoming skbs in the msk receive queue and the latter is above limits, prune it as needed quite alike what TCP is doing at the subflow level. The main difference relies in the stop condition: since MPTCP does not perform collapsing, it's better off dropping the bare minimum to fit the (newer) incoming packet. Signed-off-by: Paolo Abeni Tested-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-7-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski

mptcp: avoid code duplication in __mptcp_move_skb()

2026-08-12T01:35:38+00:00

Alike TCP, MPTCP handles in-sequence packets and partially overlapping ones in a very similar way: we can use the same path to handle both, avoiding some code duplication. This will also make the next patch simpler. Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-6-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski

mptcp: enforce hard limit on backlog flushing

2026-08-12T01:35:37+00:00

Currently a wild producer could keep the backlog flushing operation spinning for an unbound time. Since the previous patch, the amount of data present in the backlog is hard-limited. Move the backlog len update at the end of the flush loop to prevent it spinning forever. Also, no need to splice back the remaining skbs list into the backlog, as such list is always empty after each backlog processing loop. Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-5-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski

mptcp: explicitly drop over memory limits

2026-08-12T01:35:37+00:00

Currently the enforcement of the rcvbuf constraint is implemented when moving the skbs into the msk receive or OoO queue, keeping the incoming skbs in the subflow queue when over limits. Under significant memory pressure the above can cause permanent data transfer stalls, as the skb needed to make forward progress can be stuck in a subflow queue. Over memory limits, drop the incoming skb, relying on MPTCP-level retransmissions. Note that fallback socket must perform the limit before the skb reaches the subflow-level queue, as dropping an in-sequence already acked skb would break the stream. This is not a complete fix for the stall issue, as the drop strategy needs refinements that will come in the next patches. Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-4-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski

mptcp: let the retrans scheduler do its job

2026-08-12T01:35:37+00:00

Currently the MPTCP core enforces that when MPTCP-level retrans timer fires, at most a single dfrag is retransmitted. In some corner-cases, it may be necessary to retransmit multiple dfrags, and the MPTCP socket will need to wait multiple retrans timeout to accomplish that. Remove the mentioned constraint, allowing to transmit multiple dfrags per retrans period, as long as the scheduler keeps selecting subflows for retransmissions and pending data is available in the rtx queue. The default scheduler will transmit a dfrag per available subflow. Tested-by: Gang Yan Tested-by: Geliang Tang Acked-by: Geliang Tang Signed-off-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-3-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski