[PATCH mptcp-next v4] mptcp: drop skb_ext from tx clone in fallback mode

[PATCH mptcp-next v4] mptcp: drop skb_ext from tx clone in fallback mode

[Geliang Tang]

From: Geliang Tang <tanggeliang@kylinos.cn>

In fallback mode, mptcp_established_options() returns 0 and no DSS options
are generated, but __skb_clone() has already shared the skb_ext with the
transmit clone via __skb_ext_copy(), bumping its refcount. The clone holds
the reference until the peer reads data, so the ext is not freed when the
original skb is released from the rtx queue. This causes a kmemleak when
TLS ULP pushes pending records during close, as the ext lifecycle cannot
complete before kmemleak scans. Drop the ext from the clone in the fallback
path of mptcp_established_options() to eliminate the unnecessary shared
reference.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
v4:
 - drop skb_ext in mptcp_established_options in fallback mode

v3:
 - Free extensions before early returns (fixes memory leak)
 - Use fallback label to skip mpext operations (fixes NULL deref)
 - Allow TCP coalescing when mpext NULL in fallback mode
 - Remove cached fb variable to avoid race conditions (fixes NULL deref)
 - Pass fallback state to mptcp_skb_can_collapse_to() for correct behavior
 - https://patchwork.kernel.org/project/mptcp/patch/6e4266b0dc3eb7e68f0064e16fa9921f46b85319.1788338252.git.tanggeliang@kylinos.cn/

v2:
 - Free extensions before early returns
 - Added fallback label to skip mpext operations
 - Allow TCP coalescing when mpext NULL
 - Cache fallback state in bool fb
 - https://patchwork.kernel.org/project/mptcp/patch/b67dec47d321886d45fdd2bca1c303314fcdb229.1788252583.git.tanggeliang@kylinos.cn/

v1:
 - https://patchwork.kernel.org/project/mptcp/patch/70a7e7e05337faa0547c3759e5d9829763f2bcc5.1788244452.git.tanggeliang@kylinos.cn/
---
 net/mptcp/options.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 2bf3686709de..3b52e9f971f0 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -885,8 +885,12 @@ int mptcp_established_options(struct sock *sk, struct sk_buff *skb,
 	/* Force later mptcp_write_options(), but do not use any actual
 	 * option space.
 	 */
-	if (unlikely(__mptcp_check_fallback(msk) && !mptcp_check_infinite_map(skb)))
+	if (unlikely(__mptcp_check_fallback(msk) &&
+		     !mptcp_check_infinite_map(skb))) {
+		if (skb)
+			skb_ext_del(skb, SKB_EXT_MPTCP);
 		return 0;
+	}
 
 	if (unlikely(skb && TCP_SKB_CB(skb)->tcp_flags & TCPHDR_RST)) {
 		if (mptcp_established_options_fastclose(sk, &opt_size, remaining, opts) ||
-- 
2.53.0

Re: [PATCH mptcp-next v4] mptcp: drop skb_ext from tx clone in fallback mode

[MPTCP CI]

Hi Geliang,

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/34609973000

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


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)