Linux Netfilter development
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [nf-next PATCH v3 0/4] Address Sashiko review of NAT hook dump code
Date: Fri, 24 Jul 2026 12:32:14 +0200	[thread overview]
Message-ID: <amM_LjFL83jCngtg@chamomile> (raw)
In-Reply-To: <20260710151411.2358773-1-phil@nwl.cc>

Hi Phil,

I think we have to tackle this from a different angle the
nfnl_hook_dump_nat() dump issues, see:

static int nfnl_hook_dump_nat(struct sk_buff *nlskb,
                              struct netlink_callback *cb,
                              const struct nf_hook_ops *ops, int family)
...

        if ((e && i >= e->num_hook_entries) ||
            ctx->natv != (unsigned long)e) {
                cb->seq++;
                return -EINTR;
        }

Because as sashiko reports, memory address could be recycled to defeat
this which is unlikely, but correct.

Instead of making heuristics to detect if interference has happened,
I think there is a need for something like a hook_base_seq per-netns
that can be used:

        cb->seq = READ_ONCE(...hook_base_seq);

which should be bumped when updating the hook arrays via WRITE_ONCE().

Then, a call at the end of the dump:

        nl_dump_check_consistent(cb, nlmsg_hdr(skb));

will set on NLM_F_DUMP_INTR flag so userspace can retry.

I would suggest to check that i is safe to access the array, ie.

        if (i >= e->num_hook_entries)
                goto out;

and perform the netlink dump even if it will result in a stale dump,
which is what other subsystems do, ie. just add a safety check here.

We can discuss later on how to make improvements to the netlink dump
logic to detect an interference early.

Thanks.

On Fri, Jul 10, 2026 at 05:14:07PM +0200, Phil Sutter wrote:
> Changes since v2:
> - Drop patch 1 again. Fixing nfnl_hook_dump's broken NLM_F_DUMP_INTR
>   flag setting in corner-cases is out of scope of this series and should
>   be solved in a more elegant way in nfnetlink itself.
> Changes since v1:
> - New patch 1
> - Fixed three aspects of patch 3
> - Fixed two issues of patch 5
> 
> Patch 1 is mere preparation to add the missing case handling to
> nfnl_hook_dump_nat().
> 
> Patch 2 fixes for missing READ_ONCE() calls when addressing hook ops
> array elements.
> 
> Patch 3 adds missing multipart dump support to nfnl_hook_dump_nat.
> 
> Patch 4 adds code to detect and mitigate concurrent hook updates while
> amidst a multipart dump to nfnl_hook_dump_nat.
> 
> Link: https://sashiko.dev/#/patchset/20260702105003.13550-2-fw%40strlen.de
> 
> Phil Sutter (4):
>   netfilter: nfnetlink_hook: Pass cb object to nfnl_hook_dump_nat()
>   netfilter: nfnetlink_hook: Address hook ops using READ_ONCE()
>   netfilter: nfnetlink_hook: Handle multipart NAT hook dumps
>   netfilter: nfnetlink_hook: Fix for concurrent NAT hooks dump and
>     change
> 
>  net/netfilter/nfnetlink_hook.c | 48 ++++++++++++++++++++++++----------
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> -- 
> 2.54.0
> 

  parent reply	other threads:[~2026-07-24 10:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 15:14 [nf-next PATCH v3 0/4] Address Sashiko review of NAT hook dump code Phil Sutter
2026-07-10 15:14 ` [nf-next PATCH v3 1/4] netfilter: nfnetlink_hook: Pass cb object to nfnl_hook_dump_nat() Phil Sutter
2026-07-10 15:14 ` [nf-next PATCH v3 2/4] netfilter: nfnetlink_hook: Address hook ops using READ_ONCE() Phil Sutter
2026-07-10 15:14 ` [nf-next PATCH v3 3/4] netfilter: nfnetlink_hook: Handle multipart NAT hook dumps Phil Sutter
2026-07-10 15:14 ` [nf-next PATCH v3 4/4] netfilter: nfnetlink_hook: Fix for concurrent NAT hooks dump and change Phil Sutter
2026-07-24 10:32 ` Pablo Neira Ayuso [this message]
2026-07-24 10:54   ` [nf-next PATCH v3 0/4] Address Sashiko review of NAT hook dump code Pablo Neira Ayuso

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=amM_LjFL83jCngtg@chamomile \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox