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
>
next prev 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