netdev - Re: [PATCH v2] icmp: fix icmp_ndo_send address translation for reply direction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e1bf6193-d075-4593-81ef-99e8b93a4f74@blaese.de>
Date: Wed, 27 Aug 2025 19:12:19 +0200
From: Fabian Bläse <fabian@...ese.de>
To: Florian Westphal <fw@...len.de>
Cc: netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
 "Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH v2] icmp: fix icmp_ndo_send address translation for reply
 direction

On 27.08.25 11:05, Florian Westphal wrote:
> If the connection isn't subject to snat, why to we need to mangle the
> source address in the first place?
It is not limited to SNAT/MASQUERADE.
DNAT also affects which source address should be used, depending on the packet
direction.

With DNAT, the *destination* of the original direction is changed.
In the reply direction, this becomes the *source* address.

So reply packets of a DNAT connection are effectively subject to source address
translation. If icmp_ndo_send doesn’t account for this, rate limiting breaks,
which is exactly the problem this function was meant to solve.

> Don't understand this either.  Why these checks?
> AFAICS you can keep the original check in place, and then:
> 
> replace this
>>  	orig_ip = ip_hdr(skb_in)->saddr;
>> -	ip_hdr(skb_in)->saddr = ct->tuplehash[0].tuple.src.u3.ip;
> 
> ... with ...
You are right: the code can be simplified. I'm not sure show this slipped through.
I will send an updated patch with this change — thanks for the suggestion.
However, the old check (IPS_SRC_NAT only) cannot be kept, because:
- Reply packets of a DNAT connection also need handling.
- Reply packets of a pure SNAT connection don’t need it, but replacing the
   address is a no-op in that case (tuple == skb address).

To avoid unnecessary translations, I suggested the direction-specific checks.
Another option is to simplify them to:

     if (!(ct->status & IPS_NAT_MASK)) { … }

This ensures we only ever touch connections with NAT, while keeping the code
straightforward.

> Without dnat, the reply tuple saddr == original tuple daddr.
> 
> With dnat, its the dnat targets' address (i.e., the real destination
> the client is talking to).
Yes, exactly.

> If you are worried about "dnat to", then please update the commit
> message, which only mentions masquerade/snat.
Correct — the change not only fixes SNAT-in-reply handling, but also adds
proper handling for DNAT in the reply direction, which was missing entirely.
I will update the commit message to reflect this.

Best regards,
Fabian