Re: [PATCH net v4] net: Fix Hole-196 vulnerability by dropping unicast ARP/IP in L2 BMC

[Julian Anastasov]

	Hello,

On Fri, 30 Oct 2026, Star Chang wrote:

> Hi Julian,
> 
> Thank you! Your point is spot-on: in a shared-key Wi-Fi network, an attacker
> can simply broadcast a forged GARP reply (sip == tip == gateway_ip) to poison
> the gateway MAC for all peers. Giving GARP an exemption indeed leaves a door open.
> 
> We verified the Android / mobile use case and confirmed that completely
> disallowing neighbor learning from L2 BMC is safe:

	The only purpose of neigh_event_ns() is to flood the
cache with NUD_STALE entries that on confirmed traffic avoid the
ARP probing:

1. If entry was missing => create NUD_STALE entry with the hwaddr

2. If entry was present => update it only if hwaddr changes,
if hwaddr is same => do nothing

	Same is for the neigh_update() after arp_accept() for
broadcasts.

	So, if we do not want to keep STALE entries with
wrong address learned from broadcasts, we should not call 
neigh_event_ns() and the neigh_update().

> - Gateway validation: Android relies on NUD (Neighbor Unreachability Detection)
>   unicast probes and unicast replies (PACKET_HOST), never on broadcast replies.
> - Wi-Fi Roaming: Roaming clients *send* GARP to notify the AP/switch; they do
>   not need to receive broadcast GARP.
> - Router failover: NUD naturally detects stale neighbor state and re-probes
>   via unicast, recovering within seconds.
> 
> For v6, following your guidance:
> 1. L2 BMC ARP Replies:
>    Drop all of them unconditionally (including GARP) with
>    SKB_DROP_REASON_UNICAST_IN_L2_MULTICAST.
> 2. L2 BMC ARP Requests:
>    Process and send replies as usual, but suppress updating/creating neighbor
>    cache entries.
> 
> Does this match your vision for v6? If so, I will prepare the patch accordingly.

	I don't know IPv6 well, so I can not help here.

Regards

--
Julian Anastasov <ja@xxxxxx>