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

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

Message-ID: <20241118174910.7fe410bc@hermes.local>
Date: Mon, 18 Nov 2024 17:49:10 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: Etienne Buira <etienne.buira@...e.fr>
Cc: davem@...emloft.net, dsahern@...nel.org, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Bug] Linux sends poisonous ARP replies on ethernet

On Mon, 18 Nov 2024 22:14:48 +0100
Etienne Buira <etienne.buira@...e.fr> 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 stable@...r.kernel.org.
> 
> 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