Re: [PATCH mptcp-next 5/6] mptcp: trim the duplicated skb head at receive enqueue

[Paolo Abeni <pabeni@redhat.com>]

On 7/30/26 3:15 AM, Geliang Tang wrote:
> On Wed, 2026-07-29 at 10:08 +0200, Paolo Abeni wrote:
>> On 7/27/26 1:29 PM, Geliang Tang wrote:
>>> The linear readers (recvmsg, read_sock, read_done) cope with that
>>> by
>>> computing a per-skb offset = copied_seq - map_seq and skipping it.
>>> But
>>> consumers that treat the receive queue as a single contiguous byte
>>> stream cannot: the TLS strparser builds an anchor whose frag_list
>>> is
>>> the receive-queue skbs and reads it with a plain skb_copy_bits(),
>>> which
>>> has no per-skb offset knowledge. A record spanning such an skb
>>> boundary
>>> then reads the duplicated prefix and gets corrupted.
>>
>> The above raises a question.
>>
>> AFAICS, the critical skb layout is also possible with plain TCP -
>> possibly is just less likely. How does TLS deal with that? I read the
>> above as the TLS stream get corrupted, which sounds suspiciously too
>> fragile to me?!? Or did I miss something?
> 
> My description was inaccurate. This only occurs in the MPTCP out-of-
> order scenario. It does not happen with TCP.

I mean: even for plain TCP skbs can sits in the receive queue with some
heading bytes overlapping with already received ones, and skipped at
read time due to `copied_seq`, how comes that TLS has no problem is such
a case?

/P