Re: Netfilter: match "tcp option" with the same type present multiple times

[Matthieu Baerts <matttbe@kernel.org>]

On 29/09/2026 12:00, Pablo Neira Ayuso wrote:
> On Tue, Sep 29, 2026 at 11:21:15AM +0200, Matthieu Baerts wrote:
>> Hi Pablo,
>>
>> Thank you for your reply!
>>
>> On 28/09/2026 23:52, Pablo Neira Ayuso wrote:
>>> Hi Mattieu,
>>>
>>> On Mon, Sep 28, 2026 at 02:13:16PM +0200, Matthieu Baerts wrote:
>>>> Hello Netfilter devs,
>>>>
>>>> First, thank you for maintaining Netfilter in the kernel and the
>>>> userspace tools.
>>>>
>>>> The MPTCP selftests are switching from IPTables to NFTables, and
>>>> Clashiko reported that this part of a rule wouldn't match anything:
>>>>
>>>>   tcp option mptcp subtype remove-addr drop
>>>>
>>>> When an MPTCP REMOVE_ADDR suboption (type 0x30, len >=4, subtype 0x4) is
>>>> added to the TCP options, it is added after an MPTCP DSS option (type
>>>> 0x30, len >= 8, subtype 0x2). In other words, there will be two MPTCP
>>>> (type 30) options in the TCP options. It looks like Netfilter doesn't
>>>> handle that, because it stops processing other TCP options when the
>>>> expected type is found:
>>>>
>>>> net/netfilter/nft_exthdr.c:nft_exthdr_tcp_eval() {
>>>>     ...
>>>> 	for (i = sizeof(*tcph); i < tcphdr_len - 1; i += optl) {
>>>> 		optl = optlen(opt, i);
>>>>
>>>> 		if (priv->type != opt[i])
>>>> 			continue;
>>>> 		...
>>>> 		return;  // <== it will look at the first MPTCP option
>>>> 	}
>>>>     ...
>>>> }
>>>>
>>>> It looks like it shouldn't stop if the wrong subtype is found, but the
>>>> subtype is not compared there if I'm not mistaken. Should there be a fix
>>>> to support this case?
>>>
>>> Would it work for you if you can specify what TCP option you want to
>>> match? ie.
>>>  
>>>     tcp option[2] mptcp subtype remove-addr drop
>>>                ^
>>>                |
>>>                |
>>>        allow to specify a match at a given tcp option
>>
>> In my specific use-case, yes it would work. Some MPTCP sub-options will
>> always be after another one... when the Linux stack is used.
> 
> This would require a smaller patch.

I understand. But I guess that still means adding a new option.

In my case, it would work, but this might be confusing for people who
want to use this filter: they need to know if a suboption can be used
with another one. I guess they could have multiple rules to check the
presence of a suboption in the first matched type, and in a second one,
but that seems confusing. Or maybe not?

>>> Or would this be too strict for your use-case and you would prefer
>>> that you can match it anywhere?
>>
>> I think it would make more sense to match it anywhere. For example, an
>> MP_RESET can be used alone, or after an MP_FASTCLOSE. Plus some stacks
>> could reorder the options as there is no imposed order.
> 
> I think this would require a MPTCP subtype parser, ie. make kernel
> aware of MPTCP subtypes.

In nft_exthdr_tcp_eval(), why can the comparison not be done there
instead of copying the data in a register, and compare later on? If the
comparison is done directly for a given type and is different, the code
could continue and check for the same type. (Or store in multiple
registers.)

I don't know if you need something specific to MPTCP, maybe just a way
to check all options with the same type.

> I would support both of them eventually? Starting by the one above
> that allows to match at a given position which looks simpler to
> support to me. Then, look into adding a MPTCP subtype parser later?

If the second one can be implemented in a simple way, perhaps the first
one is not needed? If not, yes, good idea to start with the first one,
which might be enough for most people.

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