[PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path

[PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path

[Alexandre Ferrieux]

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

This patch fixes all similar scenarii by calling skb_scrub_pkt()
on the clone, severing its link to precious direct-path state.

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.

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

Re: [PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path

[Pablo Neira Ayuso]

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

Re: [PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path

[Alexandre Ferrieux]

On 8/5/26 10:24 AM, Pablo Neira Ayuso wrote:
> 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?
Sure:

 - assume hosts A.eth0 and B.eth0 have active production traffic (say TCP)
 - assume we have a monitoring tool on A that dups eth0's egress to some other
interface $MON

    nft add chain netdev ta ch '{type filter hook egress device "eth0" priority
filter ; policy accept ; }'
    nft add rule netdev ta ch dup to $MON

 - assume something goes wrong on $MON generating link failures. In my case it
was a GRETAP with L3 destination suddenly unreachable.

 - The next A->B packet goes through normally, but its duplicate hits
ipv4_link_failure(), hence the dst (which is B) is expired.

 - As a result, (say) TCP disruptions occur. The thermometer killed the patient :)

Note: as a straightforward repro, you can simply witness "noise" in simple ping
sessions, with ghost unreach reports muxed with normal measurement:

    ip link add gre1 type gretap remote 192.168.1.99 ;# on the LAN, nonexistent
IP => will generate link failures
    ip link set dev gre1 up
    nft add table netdev ta
    nft add chain netdev ta ch '{type filter hook egress device "eth0" priority
filter ; policy accept ; }'
    nft add rule netdev ta ch counter dup to gre1
    ping -n 8.8.8.8
 =>
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=19.9 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=12.8 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=36.0 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=30.3 ms
    From 192.168.1.13 icmp_seq=5 Destination Host Unreachable
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=115 time=31.0 ms
    From 192.168.1.13 icmp_seq=6 Destination Host Unreachable
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=115 time=38.0 ms
    From 192.168.1.13 icmp_seq=7 Destination Host Unreachable
    64 bytes from 8.8.8.8: icmp_seq=7 ttl=115 time=36.8 ms
    From 192.168.1.13 icmp_seq=8 Destination Host Unreachable
    64 bytes from 8.8.8.8: icmp_seq=8 ttl=115 time=23.5 ms
    ^C


>
>> 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.
Okay, will retarget :)

> As for the conntrack and dst, you have to explain what it breaks on
> your end.
Dst as shown above. Conntrack is more speculation, but my take is that in any
case the dup path should *never* have any kind of retroaction on the observed
path, so any "complex state" attached to the direct path should be absolutely
isolated from "whatever happens on the dup path". Am I mistaken ?

-Alex