summaryrefslogtreecommitdiff
path: root/net/mptcp
AgeCommit message (Collapse)Author
9 daysmptcp: avoid pruning for OoW dataPaolo Abeni
Pruning is expansive and destructive, do it only when we expect to accept the skb triggering the cleanup. Fixes: e468d371180d ("mptcp: implemented OoO queue pruning") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-15-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: being below memory limit is a likely() conditionPaolo Abeni
The current compiler hint annotation is wrong, due to inverted logic in the previous revision of the relevant code. Fixes: e468d371180d ("mptcp: implemented OoO queue pruning") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-14-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: options: fix uninit-value in mptcp_write_data_finMatthieu Baerts (NGI0)
When sending a DATA_FIN without data, and because the DATA_FIN occupies 1 octet of the connection-level sequence space [1], it is then required to add a DSS mapping with specific values. If the checksum has been negotiated, it also needs to be computed, and included in the outgoing packet, and thus the initial csum data needs to be reset to 0 as well. This is no longer the case since commit cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()"), because the whole ext_copy structure is no longer zeroed by default. This seems to be the only case where use_map is changed and set afterwards, so initialising the csum field only in this case, along with other fields for this specific case. Fixes: cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.3.3 [1] Link: https://sashiko.dev/#/patchset/20260812-net-next-mptcp-misc-feat-7-3-v1-0-1905a818f6cb%40kernel.org?part=2 Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-13-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: remove unneeded READ_ONCE() annotationPaolo Abeni
The subflow->fully_established flag is always written under the subflow socket lock. Reading such value under the same lock does not require any ONCE annotation. Fixes: 581c8cbfa934 ("mptcp: annotate data-races around subflow->fully_established") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-10-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: pm: reset retrans_time when ADD_ADDR entry is reusedMatthieu Baerts (NGI0)
When an ADD_ADDR entry is reused, the timer is re-armed, because the goal is to re-announce an ADD_ADDR, and eventually retransmit it if needed. In this case, the retransmission counter should be reset as well, so the re-announced address gets its retransmissions back instead of relying on what was left before, and possibly not being able to retransmit it. Fixes: 304ab97f4c7c ("mptcp: allow ADD_ADDR reissuance by userspace PMs") Cc: stable@vger.kernel.org Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=4 Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-9-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: pm: userspace: fix address ID overflowQing Luo
When all MPTCP address IDs (1-255) are exhausted in the userspace PM, find_next_zero_bit() returns MPTCP_PM_MAX_ADDR_ID + 1 (256). This value overflows when stored in the u8 field e->addr.id, resulting in ID 0 being stored and the entry being incorrectly added to the list. ID 0 is reserved for the initial connection in MPTCP, so this overflow can cause address conflicts. Note: the in-kernel PM already has an 'endpoints == MPTCP_PM_MAX_ADDR_ID' check in mptcp_pm_nl_append_new_local_addr() that returns -ERANGE before reaching find_next_zero_bit(), preventing this overflow. So this fix only addresses the userspace PM path. Check the find_next_zero_bit() result against MPTCP_PM_MAX_ADDR_ID and return -ENOSPC if all IDs are truly exhausted. Move the ID allocation check before the memory allocation so that the error path does not need to free the allocated entry. Fixes: 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo <luoqing@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-8-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: prevent race between disconnect() and rtxPaolo Abeni
Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation. Cc: stable@vger.kernel.org Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-6-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: options: handle MPC data + csum reqd + no csumMatthieu Baerts (NGI0)
Before this modification, a remote peer could send an MP_CAPABLE with data, with the checksum flag set, but without adding the actual 2 bytes of checksum. As a result, uninitialised bytes could be used for the 'csum' field. That was not a critical issue, because this 'csum' field is only used to compare with the expected one, if previously negotiated in the 3WHS. Worst case, the checksum is likely wrong, a fallback is done without a reject if the negotiation was done earlier. That's OK. Yet, better to take the expected path with this case: only look at the checksum flag for MP_CAPABLEs not carrying a data-len. Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1] that the 3rd packet should have the checksum flag set. When an MPC + ACK contains data, the checksum flag is redundant with the checksum field. It is not clear what should be done for the 4th ACK, nor if the flag has to be set if the checksum field is set. Therefore, it seems fine to only look at the presence of the checksum field, not to break the interaction with stacks that were not setting both. Note that linked to this checksum flag on the 3rd ACK, with the current implementation, we can have a situation where the SYN packets have no checksum flag, but the 3rd ACK has one, and this is the one that will be taken into account. First, that's clearly not directly linked to this patch, but Clashiko forced us to look at that. At the end, that seems fine to act like that: yes that's not how the negotiation should work, but being flexible without introducing side effects is also fine: fixing this would mean increasing the complexity, and that's not worth it. Fixes: 208e8f66926c ("mptcp: receive checksum for MP_CAPABLE with data") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-23 [1] Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=1 Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-5-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: pm: kernel: drop pending ADD_ADDR when removing ID0Kalpan Jani
The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup. Fixes: 740d798e8767 ("mptcp: remove id 0 address") Cc: stable@vger.kernel.org Reported-by: syzbot+55c2a5c871441261ed14@syzkaller.appspotmail.com Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/620 Suggested-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-4-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: syncookies: remember the request backup flagMatthieu Baerts (NGI0)
Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both. Fixes: efd340bf3d77 ("mptcp: distinguish rcv vs sent backup flag in requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-3-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: subflow: no need to copy thmac during ulp_cloneMatthieu Baerts (NGI0)
'thmac' is not used after that point. Indeed, subflow_ulp_clone() is called when the request on the passive side is over, so when the truncated HMAC is no longer needed. Note that in case of SYN cookies, thmac will not be initialised. So better to remove it to avoid a warning from debug tools like KMSAN for reading uninitialised data. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-2-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
9 daysmptcp: do not reschedule the RTX timer for fallback socketsPaolo Abeni
On fallback socket the retrans timer is a quite convoluted no-op, but currently nothing prevents the MPTCP core to keep rescheduling it. Additionally gate RTX timer reset to the msk not being fallen back to TCP yet. To avoid adding multiple tests in fast-path, use a new flags bit for such condition. The RTX enable bit is clear at close time and set before the msk could start retransmitting, with a couple of caveats: - passive sockets inherit the bit from the listener msk; set the bit on such socket to avoid flipping it in the fast-path, even if the listener will obviously never retransmit. - while fastopening (MPTFO), mptcp_sendmsg_fastopen still ends-up calling mptcp_connect via tcp_sendmsg_fastopen -> __inet_stream_connect(ssk->sk_socket), and the first subflow's sk_socket points to the msk one. Fixes: b51f9b80c032 ("mptcp: introduce MPTCP retransmission timer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-1-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-28tcp: use GFP_ATOMIC in tcp_send_active_reset()Eric Dumazet
tcp_send_active_reset() can be called from contexts where gfp_any() (in tcp_disconnect()) or sk->sk_allocation (in __tcp_close() and mptcp_do_fastclose()) evaluates to GFP_KERNEL, which includes __GFP_FS and __GFP_DIRECT_RECLAIM. Allocating with GFP_KERNEL while holding the socket lock (sk_lock) creates a lockdep dependency: sk_lock -> fs_reclaim This causes false-positive lockdep circular locking warnings with storage subsystems (such as nvme-tcp) that acquire socket locks in block I/O paths and invoke tcp_disconnect() or close sockets upon teardown: set->srcu -> sk_lock -> fs_reclaim -> elevator_lock -> set->srcu Active resets are small RST packet headers that should never enter direct reclaim or block while holding socket locks. Use sk_gfp_mask(sk, GFP_ATOMIC | __GFP_NOWARN) inside tcp_send_active_reset() and remove its priority argument. This preserves __GFP_MEMALLOC access for SOCK_MEMALLOC sockets, suppresses allocation failure warnings, and aligns with other control packet allocations (e.g. tcp_send_fin(), __tcp_send_ack(), tcp_xmit_probe_skb()). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260827095936.551524-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstructionHarshit Varu
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 <harshitvaru666@gmail.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260815115205.197151-1-harshitvaru666@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-17mptcp: add per-event MIB counters for MPTCP_RST_EMPTCP resetsShardul Bankar
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 <shardul.b@mpiricsoftware.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-5-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-17mptcp: honour configured min/max RTO in retransmit pathsKalpan Jani
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 <kalpan.jani@mpiricsoftware.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-4-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-17mptcp: pm: userspace: make remove_addr_entry staticMatthieu Baerts (NGI0)
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 <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-3-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-17mptcp: pm: add WARN_ON_ONCE guards on extra_subflows underflowTao Cui
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 <cuitao@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-1-1905a818f6cb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: implemented OoO queue pruningPaolo Abeni
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 <pabeni@redhat.com> Tested-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-7-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: avoid code duplication in __mptcp_move_skb()Paolo Abeni
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 <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-6-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: enforce hard limit on backlog flushingPaolo Abeni
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 <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-5-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: explicitly drop over memory limitsPaolo Abeni
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 <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-4-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: let the retrans scheduler do its jobPaolo Abeni
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 <yangang@kylinos.cn> Tested-by: Geliang Tang <geliang@kernel.org> Acked-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-3-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: move the stale logic out of retrans schedulerPaolo Abeni
This allow separating the stale logic invocation and the retrans scheduler, and will simplify the next patch. It's also a cleaner design as the retrans scheduler has currently too many side effects. As a possible downside, the retrans work will now traverse the subflows list additional times; that does not matter much, as this is slowpath. While at it, pick more accurate names for the involved helpers and explicitly note that the per subflow stale data is under msk socket lock protection. The scheduler and the stale logic may observe different subflow statues, as no subflow lock is acquired. This is intentional and not harmful, worst case leading to slower retransmissions. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-2-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: move the retrans loop to a separate helperPaolo Abeni
This is a cleanup in order to make the next patch simpler. No functional change intended. Tested-by: Gang Yan <yangang@kylinos.cn> Tested-by: Geliang Tang <geliang@kernel.org> Acked-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-1-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: reclaim forward-allocated memory on RX path errorsPaolo Abeni
After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped. Fixes: 9db5b3cec4ec ("mptcp: borrow forward memory from subflow") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-8-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: fastopen: only mark MPTFO subflows with SYN dataWyatt Feng
Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO". Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-7-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: pm: fix memory leak from alloc-during-teardown raceShardul Bankar
mptcp_pm_destroy() empties msk->pm.anno_list and msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket teardown, dropping the lock between the two. A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcp_token_get_sock() and, in mptcp_pm_nl_announce_doit(), calls mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcp_pm_destroy() may run on the same msk via mptcp_disconnect(), which invokes mptcp_destroy_common() without dropping the sock refcount, before the handler completes. If the lock acquisitions interleave such that mptcp_pm_destroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and mptcp_pm_addr_entry objects (from mptcp_userspace_pm_append_new_local_addr()) under sustained concurrent ANNOUNCE + close load against the userspace PM. Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by mptcp_pm_destroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcp_pm_destroy() frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the later alloc observes the bit and refuses. Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782). Fixes: 9ab4807c84a4 ("mptcp: netlink: Add MPTCP_PM_CMD_ANNOUNCE") Cc: stable@vger.kernel.org Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-6-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: pm: fix data race in add_addr timer callbackQing Luo
The timer callback reads entry->retrans_times outside pm.lock to decide whether to call mptcp_pm_subflow_established(). Since mptcp_pm_announced_del_timer() can concurrently set retrans_times = ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists. I discovered this issue while studying the code. AI tools helped me to verify the issue can potentially happen under race conditions. Use a local 'retransmit' flag set inside pm.lock to capture whether retransmission is still possible when the lock is taken. This allows to call mptcp_pm_subflow_established() accordingly, and not depending on the situation that can be different when checked outside the pm.lock. Fixes: 348d5c1dec60 ("mptcp: move to next addr when timeout") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo <luoqing@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-4-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: remove MPC && MPJ checkMatthieu Baerts (NGI0)
After the parent commit ("mptcp: avoid combining some incoming suboptions"), the parsing step no longer allow to have both the MP_CAPABLE and MP_JOIN suboptions set together. These chunks are now unreachable, these checks can then be removed. Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-3-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: avoid combining some incoming suboptionsMatthieu Baerts (NGI0)
Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN. Fixes: eda7acddf808 ("mptcp: Handle MPTCP TCP options") Cc: stable@vger.kernel.org Link: https://www.rfc-editor.org/rfc/rfc8684.html#section-3.5-5.1 [1] Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-2-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06mptcp: options: reset DSS fields in case of unexpected sizeMatthieu Baerts (NGI0)
A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size. Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d%40kernel.org?part=1 Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-1-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: fix BUILD_BUG_ON on legacy ARM configMatthieu Baerts (NGI0)
The 0-day bot managed to find kernel configs that cause build failures, e.g. when using the StrongARM SA1100 target (ARMv4). On such legacy ARM architecture, all structures are apparently aligned to 32 bits, causing build issue here. Indeed, on such architecture, 'flags' size is not equivalent to sizeof(u16) as expected, but to sizeof(u32). Instead, use memset(). It was not used before to ensure a simple clear operation was used by the compiler. But at the end, it shouldn't matter, and the compiler should optimise this to the same operation with or without memset() when -O above 0 is used. So let's switch to memset() to fix this issue, and reduce this complexity. Fixes: 5e939544f9d2 ("mptcp: fix uninit-value in mptcp_established_options") Cc: stable@vger.kernel.org Suggested-by: Frank Ranner <frank.ranner@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@intel.com/ Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-5-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: fix stale skb->sk reference on subflow closeKalpan Jani
The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely. Fixes: ee458a3f314e ("mptcp: introduce mptcp-level backlog") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni <pabeni@redhat.com> Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/621 Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: pm: userspace: fix use-after-free in get_local_idGeliang Tang
In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] <IRQ> [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel. Fixes: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Tested-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: decrement subflows counter on failed passive joinChenguang Zhao
mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path. In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back. Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter. Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close") Cc: stable@vger.kernel.org Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21mptcp: only set DATA_FIN when a mapping is presentMichael Bommarito
mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set. A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64)) which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking. Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected. Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Suggested-by: Paolo Abeni <pabeni@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260709191925.2811195-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: options: rst: drop unused skb parameterMatthieu Baerts (NGI0)
It was passed since its introduction in commit dc87efdb1a5c ("mptcp: add mptcp reset option support"), but never used. Simply removes it. Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-15-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: avoid using del_timer directlyMatthieu Baerts (NGI0)
mptcp_pm_announced_del_timer() removes the matched ADD_ADDR entry (if found) from the ADD_ADDR list only if check_id is false. That's dangerous, and not clear, because it means the caller should be free the entry only in some cases, and it easy to miss that. Instead, make it static, and call it from mptcp_pm_add_addr_echoed, which is the only other case where mptcp_pm_add_addr_del_timer should be called with check_id set to true. Bonus with that: a second call to mptcp_pm_add_addr_lookup_by_addr() can be avoided. Note that instead of adding the signature above to avoid a compilation issue because this helper is called before the definition of the function, the whole helper is moved above where it is first called. Its content is untouched, except the addition of the 'static' keyboard. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-14-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: make mptcp_pm_add_addr_send_ack staticMatthieu Baerts (NGI0)
Only used in pm.c. Note that the signature is added above: it is easier than moving the code around, because this helper depends on mptcp_pm_schedule_work which is declared below. While at it, explicitly mark it as to be called while pm->lock is held. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-13-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: remove add_ prefix from timerMatthieu Baerts (NGI0)
Similar to the two previous commits, using the 'add' prefix is confusing, also confirmed by [1]. Now that the structure has been renamed to include 'add_addr' in its name, easier to know the timer is linked to the ADD_ADDR, no need to add the confusing prefix, or an unneeded longer one. While at it, also update the ADD_ADDR timer helper to clearly specify it is linked to ADD_ADDR, and it is not there to add a new timer. Link: https://lore.kernel.org/20251117100745.1913963-1-edumazet@google.com [1] Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-12-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: uniform announced addresses helpersMatthieu Baerts (NGI0)
Similar to the previous commit, only using the 'add' or 'anno' prefixes is confusing -- generally associated to the action of adding something, or the Latin name for "year" -- and lack of uniformity. This has been causing issues in the past, e.g. del_add_timer seemed to suggest the goal is to delete a previously added timer. Instead, use the mptcp_pm_announced_ prefix. While at it, slightly improves some helpers: - mptcp_lookup_anno_list_by_saddr: no need to specify what is used to do the lookup: mptcp_pm_announced_lookup. - mptcp_pm_sport_in_anno_list: it doesn't just compare the port, but the whole address linked to the sublow: mptcp_pm_announced_has_ssk. - mptcp_pm_alloc_anno_list: it allocates one item of the list, not a whole list: mptcp_pm_announced_alloc. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-11-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: rename add_entry structure to add_addrMatthieu Baerts (NGI0)
Using only the 'add' prefix is confusing: does it refer to a generic added entry or address, or specifically to ADD_ADDRs. Using add_addr removes this confusion. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-10-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: use for_each_subflow helperMatthieu Baerts (NGI0)
Similar to most places in the MPTCP code. So instead of passing the subflow list and use list_for_each_entry(subflow, list, node), pass the msk and use mptcp_for_each_subflow(msk, subflow). That's clearer and more uniform with the rest. While at it, add 'pm_' prefix for the exported one to easily identify the origin. Plus replace 'lookup' by 'has', because a bool is returned. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-9-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: drop TCP TS with ADD_ADDRv6 + portMatthieu Baerts (NGI0)
With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port taking 30 bytes, the 40-byte limit for the TCP options is reached. In this case, it is then not possible to send the signal. To be able to send this ADD_ADDR, the TCP timestamps option can now be dropped. This is done, when needed by setting the *drop_ts parameter from mptcp_established_options. This feature is controlled by a new net.mptcp.add_addr_v6_port_drop_ts sysctl knob, enabled by default. It is important to keep in mind that dropping the TCP timestamps option for one packet of the connection could eventually disrupt some middleboxes: even if it should be unlikely, they could drop the packet or even block the connection. That's why this new feature can be controlled by a sysctl knob. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/448 Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-6-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11tcp: allow mptcp to drop TS for some packetsMatthieu Baerts (NGI0)
With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port taking 30 bytes, the 40-byte limit for the TCP options is reached. In this case, it is then not possible to send the address signal. The idea is to let MPTCP dropping the TCP-timestamps option for some specific packets, to be able to send some specific pure ACK carrying >28 bytes of MPTCP options, like with this specific ADD_ADDR. A new parameter is passed from tcp_established_options to the MPTCP side to indicate if the TCP TS option is used, and if it should be dropped. The next commit implements the part on MPTCP side, but split into two patches to help TCP maintainers to identify the modifications on TCP side. This feature will be controlled by a new add_addr_v6_port_drop_ts MPTCP sysctl knob. It is important to keep in mind that dropping the TCP timestamps option for one packet of the connection could eventually disrupt some middleboxes: even if it should be unlikely, they could drop the packet or even block the connection. That's why this new feature will be controlled by a sysctl knob. Note that it would be technically possible to squeeze both options into the header if the ADD_ADDR is first written, and then the TCP timestamps without the NOPs preceding it. But this means more modifications on TCP side, plus some middleboxes could still be disrupted by that. In this implementation, an unused bit is used in mptcp_out_options structure to avoid passing an address to a local variable. Reading and setting it needs CONFIG_MPTCP, so the whole block now has this #if condition: mptcp_established_options() is then no longer used without CONFIG_MPTCP. About alternatives, instead of passing a new boolean (has_ts), another option would be to pass the whole option structure (opts), but 'struct tcp_out_options' is currently defined in tcp_output.c, and it would need to be exported. Plus that means the removal of the TCP TS option would be done on the MPTCP side, and not here on the TCP side. It feels clearer to remove other TCP options from the TCP side, than hiding that from the MPTCP side. Yet an other alternative would be to pass the size already taken by the other TCP options, and have a way to drop them all when needed. But this feels better to target only the timestamps option where dropping it should be safe, even if it is currently the only option that would be set before MPTCP, when MPTCP is used. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-5-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: introduce add_addr_v6_port_drop_ts sysctl knobMatthieu Baerts (NGI0)
This sysctl is going to be used in the next commits to drop TCP timestamps option, to be able to send an ADD_ADDR with a v6 IP address and a port number. It is enabled by default. This knob is explicitly disabled in the MPTCP Join selftest, with the "signal addr list progresses after tx drop" subtest, to continue verifying the previous behaviour where the ADD_ADDR is not sent due to a lack of space. While at it, move syn_retrans_before_tcp_fallback down from struct mptcp_pernet, to avoid creating another 3 bytes hole. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-4-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: avoid computing add_addr size twiceMatthieu Baerts (NGI0)
mptcp_add_addr_len helper was called twice: in mptcp_pm_add_addr_signal, then just after in mptcp_established_options_add_addr. Both to check the remaining space. The second call is not needed: if there is not enough space, mptcp_pm_add_addr_signal will return false, and the caller, mptcp_established_options_add_addr, will do the same without re-checking the size again. Instead, mptcp_pm_add_addr_signal can directly set the size. Note that the returned size can be negative when other suboptions are dropped, e.g. to send an echo ADD_ADDR with a v4 address, and no port. While at it: - move mptcp_add_addr_len to pm.c, as it is now only used from there - use 'int' in mptcp_add_addr_len for the size, instead of having a mix - use a bool for 'ret' in mptcp_pm_add_addr_signal Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-3-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: pm: avoid computing rm_addr size twiceMatthieu Baerts (NGI0)
mptcp_rm_addr_len helper was called twice: in mptcp_pm_rm_addr_signal, then just after in mptcp_established_options_rm_addr. Both to check the remaining space. The second call is not needed: if there is not enough space, mptcp_pm_rm_addr_signal will return false, and the caller, mptcp_established_options_rm_addr, will do the same without re-checking the size again. Instead, mptcp_pm_rm_addr_signal can directly set the size. While at it, move mptcp_rm_addr_len to pm.c, as it is now only used there, once. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-2-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-11mptcp: options: suboptions sizes can be negativeMatthieu Baerts (NGI0)
Use a signed int for the returned size, because when other options are dropped, the size can be negative, e.g. to send an echo ADD_ADDR with a v4 address, and no port. The behaviour is not changed, because it was working as expected with an overflow. But it is clearer like this, and it will help later on. Even if, for the moment, only the ADD_ADDR size can be negative in some cases, a signed int is now used for all mptcp_established_options_*() helpers, not to mismatch the type, and as a question of uniformity. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-1-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-19 04:42:42 +0000