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

[Julian Anastasov <ja@ssi.bg>]

	Hello,

On Thu, 29 Oct 2026, Star Chang wrote:

> Hi Julian,
> 
> Thank you for the prompt feedback!
> 
> On the ARP side:
> Glad to hear that dropping non-GARP ARP Replies (ar_op == ARPOP_REPLY && sip != tip) in L2 BMC sounds like the right direction.
> 
> Regarding the points you raised:
> 1. For GARP: Leaving it to DROP_GRATUITOUS_ARP to decide makes total sense. Legitimate GARP (sip == tip) will bypass our drop check and fall through to the existing IN_DEV_DROP_GRATUITOUS_ARP logic in arp_process().

	May be DROP_UNICAST_IN_L2_MULTICAST should drop also
the GARP packets. Why should the GARP packets to be more
privileged than the other broadcast requests?

	I see your v5 and it looks like you do not take the
path to stop the broadcast requests from updating the cache.

> 2. For RFC 3927 (169.254.0.0/16): I completely agree with your concern that exempting it opens another door. Given that Hole-196 attacks typically target the subnet gateway rather than link-local addresses, keeping it simple without an exemption seems safer.

	As this is a broadcast reply, we should be concerned
if the same IP is locally configured. But what if we send
broadcast request and receive broadcast reply for such address?
I don't know if there is some support for such broadcasts.

	As result, IMHO the handling should be:

- broadcast request: do not update cache, send replies as usually.
GARP requests (ARP Announcement) should not update the cache.

- broadcast replies:
	- reply for 169.254.0.0/16: one day these should be
validated and then allowed, now dropped
	- otherwise, drop, do not update cache

- the ARP traffic on the WLAN will increase because we will not
update the cache from remote requests, only from remote unicast
replies which are in response to our broadcast requests

> Regarding your comment on the IP part ("But not sure for the IP part..."):
> Could you please elaborate on your concerns with the IP changes?

	From my notes about DHCPv4, I see broadcasts only for:

- DISCOVER: client_mac->brd, 0.0.0.0:68 -> 255.255.255.255:67
- REQUEST: UNUSED IP, client_mac->brd, 0.0.0.0:68 -> 255.255.255.255:67

	But things now may differ.
> 
> The motivation for exempting UDP port 68 was that in our lab testing, we noticed certain DHCP servers responding with unicast IP addresses over L2 broadcast, which caused legitimate lease packets to be dropped by drop_unicast_in_l2_multicast.
> 
> We would be very glad to adjust, simplify, or rethink the IP logic based on your advice.
> 
> Thanks again for your time and guidance!
> 
> Best regards,
> Star Chang

Regards

--
Julian Anastasov <ja@ssi.bg>