kernel/git/stable/linux.git/net/mptcp/protocol.h, branch linux-7.2.y

mptcp: pm: fix memory leak from alloc-during-teardown race

2026-08-06T15:46:23+00:00

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 Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-6-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski

mptcp: avoid combining some incoming suboptions

2026-08-06T15:46:23+00:00

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) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-2-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: avoid using del_timer directly

2026-06-11T22:33:39+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-14-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: make mptcp_pm_add_addr_send_ack static

2026-06-11T22:33:39+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-13-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: uniform announced addresses helpers

2026-06-11T22:33:38+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-11-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: rename add_entry structure to add_addr

2026-06-11T22:33:38+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-10-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: use for_each_subflow helper

2026-06-11T22:33:38+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-9-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: drop TCP TS with ADD_ADDRv6 + port

2026-06-11T22:33:38+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-6-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: introduce add_addr_v6_port_drop_ts sysctl knob

2026-06-11T22:33:37+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-4-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski

mptcp: pm: avoid computing add_addr size twice

2026-06-11T22:33:37+00:00

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 Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260605-net-next-mptcp-add-addr6-port-ts-v2-3-758e7ca73f4d@kernel.org Signed-off-by: Jakub Kicinski