netdev - Arp undo issue in all 2.4 and 2.6 kernel releases

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: <5D2570CAFC98974F9B6A759D1C74BAD00204911D@ex2.ms.polyserve.com>
Date:	Tue, 28 Nov 2006 11:37:22 -0800
From:	"Tim Wright" <timw@...yserve.com>
To:	<netdev@...r.kernel.org>
Cc:	"Tim Wright" <timw@...yserve.com>
Subject: Arp undo issue in all 2.4 and 2.6 kernel releases

Hi folks,
I have been tracking down a strange problem, and have a simple
"reproduce-by" and was looking for opinions from those better-versed in
the kernel networking code. Basically, it is possible to get a system
into a state where it responds to ARP requests even though no interface
has the address requested. Here is a simple reproduce-by:

Select an address in the same subnet as eth0
# ifconfig eth0:5 W.X.Y.Z netmask ... up
This works. Machine now responds to arp requests for W.X.Y.Z.
# ifconfig eth0:6 W.X.Y.Z netmask ... up
This fails as it should. But, the damage is done.
# ifconfig
You will only see eth0 and eth0:5. There is no eth0:6 interface. Good.
# ifconfig eth0:5 down
Now we are supposedly back to the original state. BUT the machine will
still respond to ARP requests for W.X.Y.Z

The easiest way to get out of this is to bring up eth0:5 again, and
bring it down again. However, this looks to me like the undo code when a
clashing address is found fails to clean up the arp side of things
correctly. Any clues here?

I am not on the netdev mailing list and will track responses on the
mailing list archives.

Thanks very much,

Tim Wright
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html