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: <CA+3n-To=jD3z+PuRN6WbNf8QYeRErcOzk-W+Lovv3x31NHH22w@mail.gmail.com>
Date: Thu, 29 Jan 2026 19:39:59 +0100
From: Marc Sune <marcdevel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
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)

Missatge de Jakub Kicinski <kuba@...nel.org> del dia dj., 29 de gen.
2026 a les 5:24:
>
> 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.

The main driver for this patchset is to remove the attack vectors
described in Note 1 and Note 2 of Patch 1/4 (in the cover letter of
RFC v1), not so much being RFC compliant. They are arguably low risk,
but I would think there is value in having them on all stable
versions. I originally targeted net and didn't add Fixes as I think
these sanity checks have never been there.

Let me know if you prefer v3 to target net-next instead.