All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org, Xiang Mei <xmei5@asu.edu>,
	Weiming Shi <bestswngs@gmail.com>
Subject: Re: [PATCH nf] netfilter: x_tables: add late validate callback for nft_compat sake
Date: Sun, 19 Apr 2026 12:59:23 +0200	[thread overview]
Message-ID: <aeS1iwP8ra-yU_Qu@strlen.de> (raw)
In-Reply-To: <aeSzcx9YmM3usuez@chamomile>

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.

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.

  reply	other threads:[~2026-04-19 10:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-19 10:45 [PATCH nf] netfilter: x_tables: add late validate callback for nft_compat sake Florian Westphal
2026-04-19 10:50 ` Pablo Neira Ayuso
2026-04-19 10:59   ` Florian Westphal [this message]
2026-04-19 11:06     ` Pablo Neira Ayuso
2026-04-19 11:19       ` Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aeS1iwP8ra-yU_Qu@strlen.de \
    --to=fw@strlen.de \
    --cc=bestswngs@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=xmei5@asu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.