Re: [PATCH net-next v3 1/4] arp: discard invalid sha addr (b/mcast ARP poison)

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

On 04/02/2026 22:11, Marc Suñé wrote:
> Prior to this commit, the ARP implementation accepted ARP req/replies
> with multicast (including broadcast) and null MAC addresses as Sender
> HW Address (SHA), and updated the ARP cache for that neighbour.
> Broadcast, multicast and null MAC addresses shall never be associated
> with a unicast or a multicast IPv4 address (see RFC1812, section 3.3.2).
> 
> ARP poisioning with a broadcast MAC address and certain multicast
> addresses, especially when poisoning a Gateway IP, have some undesired
> implications compared to an ARP poisioning with a regular MAC (see
> Note1).
> 
> Worth mentioning that if an attacker is able to ARP poison in
> a L2 segment, that in itself is probably a bigger security threat
> (Man-in-middle etc., see Note2).
> 
> However, since these MACs should never be announced as SHA,
> discard/drop ARPs with SHA={b/mcast, null}, which prevents the
> broadcast/multicast ARP poisoning vector.
> 
> Note1:
> 
> After a successful broadcast/multicast ARP poisioning attack:
> 
> 1. Unicast packets and refresh ("targeted") ARPs sent to or via
>     the poisioned IP (e.g. the default GW) are flooded by
>     bridges/switches. That is in absence of other security controls.
> 
>     Hardware swiches generally have rate-limits to prevent/mitigate
>     broadcast storms, since ARPs are usually answered by the CPU.
>     Legit unicast packets could be dropped (perf. degradation).
> 
>     Most modern NICs implement some form of L2 MAC filtering to early
>     discard irrelevant packets. In contrast to an ARP poisoning
>     attack with any other MAC, both unicast and ARP ("targeted")
>     refresh packets are passed up to the Kernel networking stack
>     (for all hosts in the L2 segment).
> 
> 2. A single forged ARP packet (e.g. for the Gateway IP) can produce
>     up to N "targeted" (to broadcast) ARPs, where N is the number of
>     hosts in the L2 segment that have an ARP entry for that IP
>     (e.g. GW), and some more traffic, since the real host will answer
>     to targeted refresh ARPs with their (real) reply.
> 
>     This is a relatively low amount of traffic compared to 1).
> 
> 3. An attacker could use this form of ARP poisoning to discover
>     all hosts in a L2 segment in a very short period of time with
>     one or few packets.
> 
>     By poisoning e.g. the default GW (likely multiple times, to
>     avoid races with real gARPs from the GW), all hosts will eventually
>     issue refresh "targeted" ARPs for the GW IP with the broadcast MAC
>     address as destination. These packets will be flooded in the L2
>     segment, revealing the presence of hosts to the attacker.
> 
>     For comparison:
>       * Passive ARP monitoring: also stealthy, but can take a long
>         time or not be possible at all in switches, as most refresh
>         ARPs are targeted.
>       * ARP req flooding: requires swiping the entire subnet. Noisy
>         and easy to detect.
>       * ICMP/L4 port scans: similar to the above.
> 
> 4. In the unlikely case that hosts were to run with
>     `/proc/sys/net/ipv4/conf/*/arp_accept=1` (unsafe, and disabled
>     by default), poisoning with the broadcast MAC could be used to
>     create significantly more broadcast traffic (low-volume
>     amplification attack).
> 
>     An attacker could send M fake gARP with a number of IP addresses,
>     where M is `/proc/sys/net/ipv4/neigh/*/gc_thresh3` (1024 by
>     default). This would result in M x R ARPs, where R is the number
>     of hosts in L2 segment with `arp_accept=1`, and likely other
>     (real) ARP replies coming from the attacked host. This starts to
>     get really relevant when R > 512, which is possible in large LANs
>     but not very common.
> 
> Note2:
> 
> However, broadcast ARP poisoning might be subtle and difficult to
> spot. These ARP packets appear on the surface as regular broadcast
> ARP requests (unless ARP hdr is inspected), traffic continues to
> flow uninterrupted (unless broadcast rate-limit in switches kick-in)
> and, the next refresh ARP reply (from the GW) or any (valid) gARP
> from the GW, will restore the original MAC in the ARP table, making
> the traffic flow normally again.
> 
> Signed-off-by: Marc Suñé <marcdevel@gmail.com>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>