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 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.