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: 3+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox