From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Alexandre Ferrieux <alexandre.ferrieux@gmail.com>
Cc: coreteam@netfilter.org, netfilter-devel@vger.kernel.org,
edumazet@google.com, alexandre.ferrieux@orange.com,
netdev@vger.kernel.org
Subject: Re: [PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path
Date: Wed, 5 Aug 2026 10:24:33 +0200 [thread overview]
Message-ID: <anLzQeYulW2CQItC@chamomile> (raw)
In-Reply-To: <20260804201150.16364-1-alexandre.ferrieux@orange.com>
Hi,
On Tue, Aug 04, 2026 at 10:11:50PM +0200, Alexandre Ferrieux wrote:
> The nftables 'dup' action clones the skb with its full glory of
> metadata, including references to its destination and conntrack
> information. As a consequence, a link failure on the duplicate's
> egress path ends up doing the same as it would for the direct path,
> for example invalidating the original packet's destination, which
> typically breaks all TCP connections to that address.
>
> In other words, the "dup" path has the potential to wreak havoc
> in the direct path as a consequence of secondary link failures. This
> is very bad behavior for a monitoring tool, which is the most
> obvious application of 'dup'.
Can you describe your use-case a bit and how it breaks?
> This patch fixes all similar scenarii by calling skb_scrub_pkt()
> on the clone, severing its link to precious direct-path state.
This patch is targetted at the net tree, but nf.git is preferred.
> Note: the second argument of skb_scrub_pkt(), the boolean "packet
> is crossing netns", is intentionally set to 'false', as a 'true'
> involves exaggerate scrubbing, e.g. of the timestamp, which a
> monitoring 'dup' typically wants to preserve.
Yes, the skb->mark should really remain in place for the duplication.
As for the conntrack and dst, you have to explain what it breaks on
your end.
> Signed-off-by: Alexandre Ferrieux <alexandre.ferrieux@orange.com>
> ---
> net/netfilter/nf_dup_netdev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
> index c6bd5c29bed6..0f47a2135955 100644
> --- a/net/netfilter/nf_dup_netdev.c
> +++ b/net/netfilter/nf_dup_netdev.c
> @@ -63,8 +63,10 @@ void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif)
> return;
>
> skb = skb_clone(pkt->skb, GFP_ATOMIC);
> - if (skb)
> + if (skb) {
> + skb_scrub_packet(skb, false);
> nf_do_netdev_egress(skb, dev, nft_hook(pkt));
> + }
> }
> EXPORT_SYMBOL_GPL(nf_dup_netdev_egress);
>
> --
> 2.47.3
>
>
next prev parent reply other threads:[~2026-08-05 8:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 20:11 [PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path Alexandre Ferrieux
2026-08-05 8:24 ` Pablo Neira Ayuso [this message]
2026-08-05 9:02 ` Alexandre Ferrieux
2026-08-11 23:19 ` Alexandre Ferrieux
2026-09-09 22:35 ` 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=anLzQeYulW2CQItC@chamomile \
--to=pablo@netfilter.org \
--cc=alexandre.ferrieux@gmail.com \
--cc=alexandre.ferrieux@orange.com \
--cc=coreteam@netfilter.org \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/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.