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

[Star Chang]

Hi Julian, Johannes,

Thank you both for the great discussion and perspectives!

Putting the two points together gives a very clear and coherent picture:

1. Julian correctly pointed out the real security risk with Hole-196:
   Attackers can abuse not only unicast ARP replies, but also broadcast GARP
   announcements (sip == tip == gateway_ip) to poison peer caches in a
   shared-key network.

2. At the same time, as Johannes reminded, Linux already has a dedicated knob
   for that specific broadcast behavior: `drop_gratuitous_arp`.

Looking at the existing architecture, the two knobs complement each other
naturally:
- `drop_unicast_in_l2_multicast`: strictly enforces the L3/L2 boundary by
  dropping unicast IP and unicast ARP replies (sip != tip) inside L2 BMC.
- `drop_gratuitous_arp`: drops broadcast GARP (sip == tip) without tangling
  broadcast filtering logic into the unicast knob.

This means users defending against Hole-196 can achieve complete coverage
by enabling both knobs on the wireless interface, without needing to overload
`drop_unicast_in_l2_multicast` or change core neighbor learning behavior.

This also means [PATCH net v5] (which dropped IP changes and strictly filtered
non-GARP replies) is architecturally aligned. We can document this dual-knob
recommendation in ip-sysctl.rst so administrators know how to fully secure
shared wireless links.

Julian, Johannes — what do you think about this unified direction?

Best regards,
Star Chang