Re: [PATCH mptcp-next v3] mptcp: fix skb_ext leak in fallback mode

[Geliang Tang <geliang@kernel.org>]

Hi Matt,

Thanks for the review.

On Wed, 2026-09-02 at 12:20 +0200, Matthieu Baerts wrote:
> Hi Geliang,
> 
> On 02/09/2026 10:39, Geliang Tang wrote:
> > From: Geliang Tang <tanggeliang@kylinos.cn>
> > 
> > In fallback mode, MPTCP sockets behave as plain TCP and should not
> > allocate
> > SKB_EXT_MPTCP for transmitted skbs. The current code
> > unconditionally
> > allocates the extension, causing memory leaks when skbs are freed
> > without
> > releasing it.
> 
> I'm surprised by this. Do you have kmemleak reports?
> 
> Or is it linked to this issue?
> 
>   https://github.com/multipath-tcp/mptcp_net-next/issues/583
> 
> I'm asking because I would think that such issues would have been
> caught
> by kmemleak, plus the fix is quite invasive.

This is another kmemleak, which only occurred when I ran the fallback
TLS test after enabling the TLS settings on the fallback socket.

> 
> > Fix by short-circuiting __mptcp_add_ext() in fallback mode and
> > skipping all
> > DSS bookkeeping in mptcp_sendmsg_frag(). Also allow TCP coalescing
> > when
> > mpext is NULL in fallback mode.
> > 
> > This latent bug will be exposed once TLS ULP support is added to
> > fallback
> > MPTCP sockets, as each sendmsg via the TLS path would leak one
> > skb_ext
> > object.
> 
> Do you mean this bug is only visible with the new feature? If yes,
> then
> no need to threat it as a fix.

In v4, I removed the "Fixes" tag and changed it to for "mptcp-next".

> 
> Then, I'm also wondering if this patch shouldn't be specific to this
> case: maybe less code should be modified to deal with fallback

Yes, it's a version with less code in v4, and it fixes the root cause
of this issue.

Thanks,
-Geliang

> sockets
> once this happens? (I'm probably missing context to really help here)
> 
> Cheers,
> Matt