Re: [PATCH nf-next RFC] netfilter: nft_exthdr: add inner option type search for MPTCP

[Matthieu Baerts <matttbe@kernel.org>]

Hi Fernando,

On 08/10/2026 19:40, Fernando Fernandez Mancera wrote:
> MPTCP carries each of its suboptions as a separate TCP option of kind
> 30. The suboption type is stored in the upper four bits of the third
> byte of the option. A single packet can therefore carry several kind 30
> options, for example a dss followed by an mp-prio.
> 
> nft_exthdr_tcp_eval() stops at the first option whose kind equals
> NFTA_EXTHDR_TYPE. A rule such as:
> 
>   tcp option mptcp subtype mp-prio drop
> 
> only ever sees the first MPTCP suboption. If that is a dss, the subtype
> comparison fails and the rule never matches, even though an mp-prio is
> present later in the same header.

Thank you for working on this!

> Add NFTA_EXTHDR_INNER_TYPE. When present, the expression keeps walking
> the options of the requested kind until one carries the requested inner
> type.  If the end of the options area is reached without a match, the
> expression behaves as if the option was not found: NFT_BREAK, or 0 when
> NFT_EXTHDR_F_PRESENT is set.
> 
> See the generated bytecodes below:
> 
> - Bytecode for matching mp-join without using NFT_EXTHDR_F_PRESENT flag.
> 
> ip mptcp_exthdr input 3 2
>   [ exthdr load tcpopt 1b @ 30 + 2 inner 1 => reg 1 ]
>   [ bitwise reg 1 = ( reg 1 & 0xf0 ) ^ 0x00 ]
>   [ cmp eq reg 1 0x10 ]
> 
> - Bytecode for matching mp-join using the NFT_EXTHDR_F_PRESENT flag.
> 
> ip mptcp_exthdr input 8 7
>   [ exthdr load tcpopt 1b @ 30 + 0 present inner 1 => reg 1 ]
>   [ cmp eq reg 1 0x01 ]
> 
> Note that while using the present flag is more efficient, if we decide
> to use it in nftables command line tool it would change the behavior
> when using old kernels reverting from false negatives to false
> positives.

Could nft use NFTA_EXTHDR_INNER_TYPE if the kernel supports it, and
fallback to the previous method if not?

Or maybe better to have a new option that will explicitly fail if the
kernel doesn't support it, not to miss packets on older kernel versions?

(...)

> diff --git a/net/netfilter/nft_exthdr.c b/net/netfilter/nft_exthdr.c
> index 861bab93f435..984b54d2c6dd 100644
> --- a/net/netfilter/nft_exthdr.c
> +++ b/net/netfilter/nft_exthdr.c

(...)

> @@ -207,7 +209,15 @@ static void nft_exthdr_tcp_eval(const struct nft_expr *expr,
>  		if (priv->type != opt[i])
>  			continue;
>  
> -		if (i + optl > tcphdr_len || priv->len + priv->offset > optl)
> +		if (i + optl > tcphdr_len)
> +			goto err;
> +
> +		if (priv->has_inner && priv->type == TCPOPT_MPTCP) {

Why does it need to be limited to MPTCP?

(I understand it is probably easier like that, and that's fine for my
use-case, but I'm just thinking about extensions that could be done only
via the userspace.)

> +			if (!(optl >= 3 && (opt[i + 2] >> 4) == priv->inner_type))

Can you not use priv->offset and priv->len not to have something
specific to MPTCP?

But then, you need to keep the safety check around them before this. And
you probably need to check that the length is <= 8 at parsing time.

(...)

> @@ -679,6 +706,11 @@ static int nft_exthdr_dump_common(struct sk_buff *skb, const struct nft_exthdr *
>  		goto nla_put_failure;
>  	if (nla_put_be32(skb, NFTA_EXTHDR_OP, htonl(priv->op)))
>  		goto nla_put_failure;
> +	if (priv->has_inner) {
> +		if (nla_put_be32(skb, NFTA_EXTHDR_INNER_TYPE,  htonl(priv->inner_type)))

(double spaces before htonl())

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