netdev - Re: [PATCH net v2 0/4] discard ARP/NDP b/mcast/null announce (poison)

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: <20260128202406.69c1eef1@kernel.org>
Date: Wed, 28 Jan 2026 20:24:06 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Marc Suñé <marcdevel@...il.com>
Cc: willemdebruijn.kernel@...il.com, pabeni@...hat.com,
 netdev@...r.kernel.org, dborkman@...nel.org, vadim.fedorenko@...ux.dev
Subject: Re: [PATCH net v2 0/4] discard ARP/NDP b/mcast/null announce
 (poison)

On Tue, 27 Jan 2026 00:53:01 +0100 Marc Suñé wrote:
> The current ARP and NDP implementations accept announcements with
> multicast (broadcast incl.) and null MAC addresses as Sender HW Address
> (SHA) in ARP or src/target lladdr in NDP, and updates the cache
> for that neighbour.
> 
> Multicast (incl. broadcast) and null MAC addresses shall never be
> associated with a unicast or a multicast IPv4/6 address (see RFC1812,
> section 3.3.2).
> 
> ARP/NDP poisioning with a broadcast and certain multicast MAC addresses,
> especially when poisoning a Gateway IP, have some undesired implications
> compared to an ARP/NDP poisioning with a regular MAC (see commit message
> in patch 1 for more information).
> 
> Worth mentioning that if an attacker is able to ARP/NDP poison in
> a L2 segment, that in itself is probably a bigger security threat
> (Man-in-middle etc., see Note2 in patch 1)
> 
> Since these MACs should never be announced, this patch series discards/drops
> these packets, which prevents broadcast and multicast ARP/NDP poisoning
> vectors.
> 
> This patchset only modifies the behaviour of the neighbouring subsystem
> when processing network packets. Static entries can still be added with
> mcast/bcast/null MACs.

Not a very strong opinion but my intuition would be to target 
this to net-next. I read it as an improvement to RFC compliance
more than a solution.