linux-kernel - Wrong source address selection in arp

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>] [day] [month] [year] [list]

Message-ID: <eykjh3y2bse2tmhn5rn2uvztoepkbnxpb7n2pvwq62pjetdu7o@r46lgxf4azz7>
Date: Fri, 17 Oct 2025 16:47:27 +0200
From: Gabriel Goller <g.goller@...xmox.com>
To: "David S. Miller" <davem@...emloft.net>, 
	David Ahern <dsahern@...nel.org>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Wrong source address selection in arp_solicit for forwarded packets

Hi,
I have a question about the arp solicit behavior:

I have the following simple infrastructure with linux hosts where the ip
addresses are configured on dummy interfaces and all other interfaces are
unnumbered:

   ┌────────┐     ┌────────┐     ┌────────┐  
   │ node1  ├─────┤ node2  ├─────┤ node3  │  
   │10.0.1.1│     │10.0.1.2│     │10.0.1.3│  
   └────────┘     └────────┘     └────────┘  

All nodes have routes configured and can ping each other. ipv4 forwarding is
enabled on all nodes, so pinging from node1 to node3 should work. However, I'm
encountering an issue where node2 does not send correct arp solicitation
packets when forwarding icmp packets from node1 to node3.

For example, when pinging from node1 to node3, node2 sends out the
following arp packet:

13:57:43.198959 bc:24:11:a4:f6:cd > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100),
length 46: vlan 300, p 0, ethertype ARP (0x0806), Ethernet (len 6),
IPv4 (len 4), Request who-has 10.0.1.3 tell 172.16.0.102, length 28

Here, 172.16.0.102 is an ip address configured on a different interface on
node2. This request will never receive a response because `rp_filter=2`.

node2 has the following (correct) routes installed:

10.0.1.3 nhid 18 via 10.0.1.3 dev ens22 proto openfabric src 10.0.1.2 metric 20 onlink

Since arp_announce is set to 0 (the default), arp_solicit selects the first
interface with an ip address (inet_select_addr), which results in
selecting the wrong source address (172.16.0.102) for the arp request.
Because rp_filter is set to 2, we won't receive an answer to this arp
packet, and the ping will fail unless we explicitly ping from node2 to
node3.

I'm wondering if it would be possible (and correct) to modify arp_solicit to
perform a fib lookup to check if there's a route with an explicit source
address (e.g., the route above using src 10.0.1.2) and use that address as the
source address for the arp packet. Of course, this wouldn't be backward
compatible, as some users might rely on the current interface ordering behavior
(or the loopback interface being selected first), so it would need to be
controlled via a sysctl configuration flag. Perhaps I'm missing something
obvious here though.

Any insights would be appreciated!

Gabriel