Re: [PATCH nf] netfilter: x_tables: add late validate callback for nft_compat sake

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sun, Apr 19, 2026 at 12:59:23PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Sun, Apr 19, 2026 at 12:45:05PM +0200, Florian Westphal wrote:
> > > x_tables and nftables are fundamentally different.
> > > In x_tables, one gets the full ruleset graph via setsockopt().
> > > ->checkentry() gets called at ruleset validation time.
> > > 
> > > In nf_tables, you get a transactional request (rule add in this case)
> > > in netlink format.  At this time, it is not yet knowm from which
> > > basechain(s) the new expression is reachable.
> > >
> > > In nf_tables, there is one final hook validation pass right before the
> > > point-of-no-return when the new state is fully known.
> > >
> > > However, nft_compat calls the x_tables checkentry functions way too
> > > early, at expression instantiation time, when we have the netlink
> > > info available but not the base chain info (not yet known).
> > 
> > There used to be full validation of the table in each transaction in
> > nf_tables.
> > 
> > What happened?
> 
> As far as I can see this never worked correctly.
> 
> A few matches/targets perform hook_mask checks in ->checkentry(), but
> nft_compat calls ->checkentry() at expression init stage, which is too
> early and only catches problems if the target/match is called from
> basechain.

There is nft_{match,target}_validate() which check against
{match,target}->hooks and select_ops sets ops->validate accordingly.

Maybe this broke with your updates to speed up chain graph validation?

> iptables-nft -t raw -A PREROUTING -p tcp -j TCPMSS --clamp-mss-to-pmtu
> -> rejected at expression init time from ->checkentry()
> 
> iptables-nft -t raw -N FOO
> iptables-nft -t raw -A FOO -p tcp -j TCPMSS --clamp-mss-to-pmtu
> -> works, non-basechain
> iptables-nft -t raw -A PREROUTING -j FOO
> -> works before this patch: ->checkentry not called again
> (and we can't call it twice either as these functions are allowed
>  to have side effects such as proc file creation, kmalloc etc).
> 
> I don't see another practicable solution for this problem except
> this hack.