Re: [PATCH net 1/5] mptcp: avoid combining some incoming suboptions

[Matthieu Baerts <matttbe@kernel.org>]

Hi Jakub,

On 30/07/2026 02:23, Jakub Kicinski wrote:
> On Tue, 28 Jul 2026 19:11:57 +0200 Matthieu Baerts (NGI0) wrote:
>> 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.
> 
> Looks like Clashiko has much to say about this patch.
> Could you check?

Sure, I will check that.

Do you think Clashiko could look at patches from the MPTCP ML as well?
Because the (deprecated?) AI review tool we use didn't find anything:


https://netdev-ai.bots.linux.dev/ai-review.html?id=d1d1ff69-0f15-4812-ad16-e4f6f2df9f6b

Or maybe that's because the model is different, and this can be easily
fixed? Or maybe the prompts are different too?

I'm asking, mainly because once patches have been accepted in our tree,
it can be hard to have the original author fixing them. Not to block
other patches too long, I often have to fix them, so I would prefer to
get the same review tools (if possible) to prevent that :)

> From my perspective I'm not sure if such RFC compliance changes
> really belong as Fixes? I don't feel too strongly tho.

I think this fix is important: it is not really about RFC compliances,
but more about the fact the rest of the code is not taking into account
suboptions combinations. For example, if the same suboption is present
twice, but with different values, then the parsing will end up with a
mix of the two. Also, when such combinations are used, it is likely the
remote peer is attempting an attack, so better to block this early.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.