Subject: Re: [Bug] Linux sends poisonous ARP replies on ethernet

From: Stephen Hemminger <[email-masked]>
Date: Mon, 18 Nov 2024 17:49:10 -0800

On Mon, 18 Nov 2024 22:14:48 +0100
Etienne Buira <[email-masked]> wrote:

> Hi all,
> 
> I found problematic behaviours in linux network stack, which all look
> so related i make a single bug-report.
> 
> The underlying bug(s) might be ancient (i previously had strange
> behaviours that could be caused by this), therefore fixes should
> probably find their way to [email-masked].
> 
> The configuration:
> Two boxes are present on a dedicated virtual hub, both run
> linux-torvalds b5a24181e461e8bfa8cdf35e1804679dc1bebcdd configured with
> attached linux.config file and untainted, under qemu (Gentoo's version
> 8.2.3) as kvm guests using virtio NICs.
> 
> box1:
>   # ip a
> 	1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> 	    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 	    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> 	       valid_lft forever preferred_lft forever
> 	2: nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> 	    link/ether 00:16:3e:00:00:04 brd ff:ff:ff:ff:ff:ff
> 	    inet 10.0.1.1/24 brd 10.0.1.255 scope global nic0
> 	       valid_lft forever preferred_lft forever
> 	3: nic1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> 	    link/ether 00:16:3e:00:00:01 brd ff:ff:ff:ff:ff:ff
> 	    inet 10.0.0.1/24 brd 10.0.0.255 scope global nic1
> 	       valid_lft forever preferred_lft forever
> 	4: nic2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> 	    link/ether 00:16:3e:00:00:02 brd ff:ff:ff:ff:ff:ff
> 	    inet 10.0.0.2/24 brd 10.0.0.255 scope global nic2
> 	       valid_lft forever preferred_lft forever
> 
> box2:
>   # ip a
> 	1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> 	    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 	    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> 	       valid_lft forever preferred_lft forever
> 	2: nic3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> 	    link/ether 00:16:3e:00:00:03 brd ff:ff:ff:ff:ff:ff
> 	    inet 10.0.0.3/24 brd 10.0.0.255 scope global nic3
> 	       valid_lft forever preferred_lft forever
> 
> 
> 
> The problem i found is that linux replies to ARP requests not directed
> at it, this behaviour is not complying with RFC826:
> box2# arping -c 5 10.0.0.2 -I nic3
> 	ARPING 10.0.0.2 from 10.0.0.3 nic3
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:04] 2.285ms
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:01] 2.357ms
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 2.368ms
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.598ms
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.771ms
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.600ms
> 	Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.627ms
> 	Sent 5 probe(s) (0 broadcast(s))
> 	Received 7 response(s) (0 request(s), 0 broadcast(s))
> 
> Here, all box1's NICs have replied with their own ethernet address(!),
> including 00:16:3e:00:00:04 which is not even on the same IP network.

> 
> Unfortunately, i cannot afford to get familiar enough with linux's
> network stack to fix it without sponsorship.
> 
> Best wishes.
> 

It is not a bug.

Linux uses the weak host model https://en.wikipedia.org/wiki/Host_model

You can control how ARP is handled via the arp_ignore sysctl as
documented here:

https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html