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

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

[Star Chang]

Wi-Fi 802.11 to 802.3 frame translation allows attackers to inject
unicast L3 packets or ARP payloads inside GTK-encrypted L2 broadcast
and multicast (BMC) frames (the "Hole-196" vulnerability).

While the `drop_unicast_in_l2_multicast` sysctl was introduced to drop
unicast IPv4/IPv6 packets received over L2 BMC, it had several gaps:

1. ARP packets were not checked in `net/ipv4/arp.c`, allowing attackers
   to perform ARP poisoning via L2 BMC frames (`group-arp-unicast`).
2. Enforcement lacked DHCP client (UDP port 68) exemption, which could
   discard legitimate DHCP server responses sent via L2 broadcast.
3. Dropped packets were silently discarded without warnings or MIB stats.

The issue was identified via manual code inspection and protocol security
analysis of cross-station frame injection in 802.11 shared-key (GTK)
networks. In laboratory testing, crafted 802.11 broadcast frames containing
unicast ARP payloads (e.g. ARPOP_REQUEST / ARPOP_REPLY with tha set to a
victim's unicast MAC) bypassed the existing sysctl, poisoning the victim's
ARP cache. Furthermore, per RFC 2131 inspection, unconditionally dropping
L2 broadcast frames carrying unicast IP addresses discards standard DHCP
server responses (DHCPOFFER/DHCPACK) destined for UDP port 68 during lease
negotiation.

Enhance `drop_unicast_in_l2_multicast` sysctl enforcement:
- Extend sysctl checks to `net/ipv4/arp.c` (`arp_process()`) to drop
  unsolicited ARP Replies and ARP Requests with a non-zero unicast
  Target Hardware Address (tha) received over L2 BMC.
- Exempt Gratuitous ARP (GARP) and RFC 5227 Address Announcements
  (`sip == tip`) from L2 BMC unicast drop logic so they defer to the
  `DROP_GRATUITOUS_ARP` sysctl, preserving VRRP/HSRP router failover.
- Exempt non-fragmented DHCP client traffic (UDP dest port 68) in
  `net/ipv4/ip_input.c` and safely reload `ip_hdr(skb)` after
  `pskb_may_pull()` to prevent dangling pointer access.
- Log rate-limited warnings (`pr_warn_ratelimited`) and increment MIB
  error counters (`IPSTATS_MIB_INHDRERRORS`) for dropped frames.

Fixes: 12b74dfadb5a ("ipv4: add option to drop unicast encapsulated in L2 multicast")
Fixes: abbc30436d39 ("ipv6: add option to drop unicast encapsulated in L2 multicast")
Signed-off-by: Star Chang <starchang@google.com>
---
v2 -> v3:
  - Add Fixes: tags for commits 12b74dfadb5a and abbc30436d39.
  - Reformat lines in net/ipv4/ip_input.c to adhere strictly to the 80-column
    limit.
  - CC maintainers Ido Schimmel and Simon Horman per netdev bot check.
v1 -> v2:
  - Clarified discovery method (manual code inspection and protocol analysis)
    and triggering context in commit message per netdev-bot automated feedback.
 net/ipv4/arp.c       | 29 +++++++++++++++++++++++++++++
 net/ipv4/ip_input.c  | 32 ++++++++++++++++++++++++++++++--
 net/ipv6/ip6_input.c |  2 ++
 3 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index d409f606aec0..ad23db2e2f59 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -791,6 +791,35 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
 		goto out_free_skb;
 
+/*
+ * Hole-196 defense for ARP:
+ * If drop_unicast_in_l2_multicast sysctl is enabled on this interface,
+ * drop ARP Replies in L2 BMC frames, and ARP Requests in L2 BMC frames
+ * that specify a non-zero unicast Target Hardware Address (tha).
+ *
+ * Legitimate Gratuitous ARP (GARP) and RFC 5227 Address Announcements
+ * require (sip == tip) and tha matching sha (tha == sha). Only valid
+ * GARP frames are exempted so they defer to DROP_GRATUITOUS_ARP below.
+ */
+	if ((skb->pkt_type == PACKET_BROADCAST ||
+	     skb->pkt_type == PACKET_MULTICAST) &&
+	    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
+		bool is_valid_garp = (sip == tip) && tha &&
+				     !memcmp(tha, sha, dev->addr_len);
+
+		if (arp->ar_op == htons(ARPOP_REPLY) && !is_valid_garp) {
+			net_warn_ratelimited("Drop ARP Reply in L2 BMC on %s\n",
+					     dev->name);
+			goto out_free_skb;
+		}
+		if (dev->addr_len == ETH_ALEN && tha &&
+		    is_valid_ether_addr(tha) && !is_valid_garp) {
+			net_warn_ratelimited("Drop unicast THA ARP Req in L2 BMC on %s\n",
+					     dev->name);
+			goto out_free_skb;
+		}
+	}
+
  /*
   *	For some 802.11 wireless deployments (and possibly other networks),
   *	there will be an ARP proxy and gratuitous ARP frames are attacks
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 9860178752b8..75a5c2059632 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -456,10 +456,38 @@ static int ip_rcv_finish_core(struct net *net,
 		 * this is 802.11 protecting against cross-station spoofing (the
 		 * so-called "hole-196" attack) so do it for both.
 		 */
+		/* Hole-196 defense:
+		 * Drop unicast IP packets received over L2 BMC frames.
+		 * Exempt DHCP client responses (UDP port 68).
+		 */
 		if (in_dev &&
 		    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
-			drop_reason = SKB_DROP_REASON_UNICAST_IN_L2_MULTICAST;
-			goto drop;
+			bool is_dhcp_resp = false;
+
+			iph = ip_hdr(skb);
+			if (iph->protocol == IPPROTO_UDP &&
+			    !ip_is_fragment(iph) &&
+			    pskb_may_pull(skb, iph->ihl * 4 +
+					       sizeof(struct udphdr))) {
+				const struct udphdr *uh;
+
+				iph = ip_hdr(skb);
+				uh = (const struct udphdr *)
+					(skb_network_header(skb) +
+					 iph->ihl * 4);
+				if (uh->dest == htons(68))
+					is_dhcp_resp = true;
+			}
+
+			if (!is_dhcp_resp) {
+				net_warn_ratelimited("Drop unicast IP %pI4 in L2 BMC on %s
+",
+						     &iph->daddr, dev->name);
+				__IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
+				drop_reason =
+					SKB_DROP_REASON_UNICAST_IN_L2_MULTICAST;
+				goto drop;
+			}
 		}
 	}
 
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 8972863c93ee..caf9811f6352 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -278,6 +278,8 @@ static struct sk_buff *ip6_rcv_core(struct sk_buff *skb, struct net_device *dev,
 	    (skb->pkt_type == PACKET_BROADCAST ||
 	     skb->pkt_type == PACKET_MULTICAST) &&
 	    READ_ONCE(idev->cnf.drop_unicast_in_l2_multicast)) {
+		net_warn_ratelimited("IPv6: Drop unicast IP %pI6c in L2 BMC on %s\n",
+				     &hdr->daddr, dev->name);
 		SKB_DR_SET(reason, UNICAST_IN_L2_MULTICAST);
 		goto err;
 	}
-- 
2.56.0.257.gf7497c7d27-goog

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

[Star Chang]

Wi-Fi 802.11 to 802.3 frame translation allows attackers to inject
unicast L3 packets or ARP payloads inside GTK-encrypted L2 broadcast
and multicast (BMC) frames (the "Hole-196" vulnerability).

While the `drop_unicast_in_l2_multicast` sysctl was introduced to drop
unicast IPv4/IPv6 packets received over L2 BMC, it had several gaps:

1. ARP packets were not checked in `net/ipv4/arp.c`, allowing attackers
   to perform ARP poisoning via L2 BMC frames (`group-arp-unicast`).
2. Enforcement lacked DHCP client (UDP port 68) exemption, which could
   discard legitimate DHCP server responses sent via L2 broadcast.
3. Dropped packets were silently discarded without warnings or MIB stats.

The issue was identified via manual code inspection and protocol security
analysis of cross-station frame injection in 802.11 shared-key (GTK)
networks. In laboratory testing, crafted 802.11 broadcast frames containing
unicast ARP payloads (e.g. ARPOP_REQUEST / ARPOP_REPLY with tha set to a
victim's unicast MAC) bypassed the existing sysctl, poisoning the victim's
ARP cache. Furthermore, per RFC 2131 inspection, unconditionally dropping
L2 broadcast frames carrying unicast IP addresses discards standard DHCP
server responses (DHCPOFFER/DHCPACK) destined for UDP port 68 during lease
negotiation.

Enhance `drop_unicast_in_l2_multicast` sysctl enforcement:
- Extend sysctl checks to `net/ipv4/arp.c` (`arp_process()`) to drop
  unsolicited ARP Replies and ARP Requests with a non-zero unicast
  Target Hardware Address (tha) received over L2 BMC.
- Exempt Gratuitous ARP (GARP) and RFC 5227 Address Announcements
  (`sip == tip`) from L2 BMC unicast drop logic so they defer to the
  `DROP_GRATUITOUS_ARP` sysctl, preserving VRRP/HSRP router failover.
- Exempt non-fragmented DHCP client traffic (UDP dest port 68) in
  `net/ipv4/ip_input.c` and safely reload `ip_hdr(skb)` after
  `pskb_may_pull()` to prevent dangling pointer access.
- Log rate-limited warnings (`net_warn_ratelimited`) and increment MIB
  error counters (`IPSTATS_MIB_INHDRERRORS`) for dropped frames.

Fixes: 12b74dfadb5a ("ipv4: add option to drop unicast encapsulated in L2 multicast")
Fixes: abbc30436d39 ("ipv6: add option to drop unicast encapsulated in L2 multicast")
Signed-off-by: Star Chang <starchang@google.com>
---
v3 -> v4:
  - Fix broken newline syntax in net_warn_ratelimited() string literal
    in net/ipv4/ip_input.c that caused build failures across 32-bit,
    allmodconfig, and clang CI builds.
  - CC Julian Anastasov (ja@ssi.bg) per netdev-bot blamed author check.
v2 -> v3:
  - Add Fixes: tags for commits 12b74dfadb5a and abbc30436d39.
  - Reformat lines in net/ipv4/ip_input.c to adhere strictly to the 80-column limit.
  - CC maintainers Ido Schimmel and Simon Horman per netdev bot check.
v1 -> v2:
  - Clarified discovery method and triggering context per netdev-bot feedback.

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index d409f606aec0..ad23db2e2f59 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -791,6 +791,35 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
 		goto out_free_skb;
 
+/*
+ * Hole-196 defense for ARP:
+ * If drop_unicast_in_l2_multicast sysctl is enabled on this interface,
+ * drop ARP Replies in L2 BMC frames, and ARP Requests in L2 BMC frames
+ * that specify a non-zero unicast Target Hardware Address (tha).
+ *
+ * Legitimate Gratuitous ARP (GARP) and RFC 5227 Address Announcements
+ * require (sip == tip) and tha matching sha (tha == sha). Only valid
+ * GARP frames are exempted so they defer to DROP_GRATUITOUS_ARP below.
+ */
+	if ((skb->pkt_type == PACKET_BROADCAST ||
+	     skb->pkt_type == PACKET_MULTICAST) &&
+	    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
+		bool is_valid_garp = (sip == tip) && tha &&
+				     !memcmp(tha, sha, dev->addr_len);
+
+		if (arp->ar_op == htons(ARPOP_REPLY) && !is_valid_garp) {
+			net_warn_ratelimited("Drop ARP Reply in L2 BMC on %s\n",
+					     dev->name);
+			goto out_free_skb;
+		}
+		if (dev->addr_len == ETH_ALEN && tha &&
+		    is_valid_ether_addr(tha) && !is_valid_garp) {
+			net_warn_ratelimited("Drop unicast THA ARP Req in L2 BMC on %s\n",
+					     dev->name);
+			goto out_free_skb;
+		}
+	}
+
  /*
   *	For some 802.11 wireless deployments (and possibly other networks),
   *	there will be an ARP proxy and gratuitous ARP frames are attacks
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 9860178752b8..7d6d3e72e557 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -456,10 +456,37 @@ static int ip_rcv_finish_core(struct net *net,
 		 * this is 802.11 protecting against cross-station spoofing (the
 		 * so-called "hole-196" attack) so do it for both.
 		 */
+		/* Hole-196 defense:
+		 * Drop unicast IP packets received over L2 BMC frames.
+		 * Exempt DHCP client responses (UDP port 68).
+		 */
 		if (in_dev &&
 		    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
-			drop_reason = SKB_DROP_REASON_UNICAST_IN_L2_MULTICAST;
-			goto drop;
+			bool is_dhcp_resp = false;
+
+			iph = ip_hdr(skb);
+			if (iph->protocol == IPPROTO_UDP &&
+			    !ip_is_fragment(iph) &&
+			    pskb_may_pull(skb, iph->ihl * 4 +
+					       sizeof(struct udphdr))) {
+				const struct udphdr *uh;
+
+				iph = ip_hdr(skb);
+				uh = (const struct udphdr *)
+					(skb_network_header(skb) +
+					 iph->ihl * 4);
+				if (uh->dest == htons(68))
+					is_dhcp_resp = true;
+			}
+
+			if (!is_dhcp_resp) {
+				net_warn_ratelimited("Drop unicast IP %pI4 in L2 BMC on %s\n",
+						     &iph->daddr, dev->name);
+				__IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
+				drop_reason =
+					SKB_DROP_REASON_UNICAST_IN_L2_MULTICAST;
+				goto drop;
+			}
 		}
 	}
 
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 8972863c93ee..caf9811f6352 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -278,6 +278,8 @@ static struct sk_buff *ip6_rcv_core(struct sk_buff *skb, struct net_device *dev,
 	    (skb->pkt_type == PACKET_BROADCAST ||
 	     skb->pkt_type == PACKET_MULTICAST) &&
 	    READ_ONCE(idev->cnf.drop_unicast_in_l2_multicast)) {
+		net_warn_ratelimited("IPv6: Drop unicast IP %pI6c in L2 BMC on %s\n",
+				     &hdr->daddr, dev->name);
 		SKB_DR_SET(reason, UNICAST_IN_L2_MULTICAST);
 		goto err;
 	}

-- 
2.43.0

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

[Julian Anastasov]

	Hello,

On Tue, 27 Oct 2026, Star Chang wrote:

> Wi-Fi 802.11 to 802.3 frame translation allows attackers to inject
> unicast L3 packets or ARP payloads inside GTK-encrypted L2 broadcast
> and multicast (BMC) frames (the "Hole-196" vulnerability).
> 
> While the `drop_unicast_in_l2_multicast` sysctl was introduced to drop
> unicast IPv4/IPv6 packets received over L2 BMC, it had several gaps:
> 
> 1. ARP packets were not checked in `net/ipv4/arp.c`, allowing attackers
>    to perform ARP poisoning via L2 BMC frames (`group-arp-unicast`).
> 2. Enforcement lacked DHCP client (UDP port 68) exemption, which could
>    discard legitimate DHCP server responses sent via L2 broadcast.
> 3. Dropped packets were silently discarded without warnings or MIB stats.
> 
> The issue was identified via manual code inspection and protocol security
> analysis of cross-station frame injection in 802.11 shared-key (GTK)
> networks. In laboratory testing, crafted 802.11 broadcast frames containing
> unicast ARP payloads (e.g. ARPOP_REQUEST / ARPOP_REPLY with tha set to a
> victim's unicast MAC) bypassed the existing sysctl, poisoning the victim's
> ARP cache. Furthermore, per RFC 2131 inspection, unconditionally dropping
> L2 broadcast frames carrying unicast IP addresses discards standard DHCP
> server responses (DHCPOFFER/DHCPACK) destined for UDP port 68 during lease
> negotiation.
> 
> Enhance `drop_unicast_in_l2_multicast` sysctl enforcement:
> - Extend sysctl checks to `net/ipv4/arp.c` (`arp_process()`) to drop
>   unsolicited ARP Replies and ARP Requests with a non-zero unicast
>   Target Hardware Address (tha) received over L2 BMC.
> - Exempt Gratuitous ARP (GARP) and RFC 5227 Address Announcements
>   (`sip == tip`) from L2 BMC unicast drop logic so they defer to the
>   `DROP_GRATUITOUS_ARP` sysctl, preserving VRRP/HSRP router failover.
> - Exempt non-fragmented DHCP client traffic (UDP dest port 68) in
>   `net/ipv4/ip_input.c` and safely reload `ip_hdr(skb)` after
>   `pskb_may_pull()` to prevent dangling pointer access.
> - Log rate-limited warnings (`net_warn_ratelimited`) and increment MIB
>   error counters (`IPSTATS_MIB_INHDRERRORS`) for dropped frames.
> 
> Fixes: 12b74dfadb5a ("ipv4: add option to drop unicast encapsulated in L2 multicast")
> Fixes: abbc30436d39 ("ipv6: add option to drop unicast encapsulated in L2 multicast")
> Signed-off-by: Star Chang <starchang@google.com>
> ---
> v3 -> v4:
>   - Fix broken newline syntax in net_warn_ratelimited() string literal
>     in net/ipv4/ip_input.c that caused build failures across 32-bit,
>     allmodconfig, and clang CI builds.
>   - CC Julian Anastasov (ja@ssi.bg) per netdev-bot blamed author check.
> v2 -> v3:
>   - Add Fixes: tags for commits 12b74dfadb5a and abbc30436d39.
>   - Reformat lines in net/ipv4/ip_input.c to adhere strictly to the 80-column limit.
>   - CC maintainers Ido Schimmel and Simon Horman per netdev bot check.
> v1 -> v2:
>   - Clarified discovery method and triggering context per netdev-bot feedback.
> 
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index d409f606aec0..ad23db2e2f59 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -791,6 +791,35 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
>  	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
>  		goto out_free_skb;
>  
> +/*
> + * Hole-196 defense for ARP:
> + * If drop_unicast_in_l2_multicast sysctl is enabled on this interface,
> + * drop ARP Replies in L2 BMC frames, and ARP Requests in L2 BMC frames
> + * that specify a non-zero unicast Target Hardware Address (tha).
> + *
> + * Legitimate Gratuitous ARP (GARP) and RFC 5227 Address Announcements
> + * require (sip == tip) and tha matching sha (tha == sha). Only valid
> + * GARP frames are exempted so they defer to DROP_GRATUITOUS_ARP below.
> + */
> +	if ((skb->pkt_type == PACKET_BROADCAST ||
> +	     skb->pkt_type == PACKET_MULTICAST) &&
> +	    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
> +		bool is_valid_garp = (sip == tip) && tha &&
> +				     !memcmp(tha, sha, dev->addr_len);

	I'm not sure how much from the Sashiko review is addressed:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261002082336.608201-1-starchang%40google.com

	But matching sha and tha for requests is wrong.

From RFC 826:

===
The target hardware address is included for completeness and
network monitoring.  It has no meaning in the request form, since
it is this number that the machine is requesting.  Its meaning in
the reply form is the address of the machine making the request.
===

	tha is used only for monitoring. Linux copies sha from
requests into tha field in the reply. It does not use the tha
to update the cached entry, instead sha is used for this.

	From RFC 2002, section 4.6, about Gratuitous ARP:

===
When using an ARP Reply packet, the
Target Hardware Address is also set to the link-layer address to
which this cache entry should be updated (this field is not used
in an ARP Request packet).
===

	It means to store the sender address there too. But as we
see nobody updates cache from tha, only from sha. But there are
GARP implementations that store broadcast address in tha when
sending broadcast GARP reply, may be because the packet is intended
to ALL, not just to simulate a reply packet addressed to the sender.

	So, I'm not sure why arp_is_garp() requires tha and
sha to match for GARP reply. It is too restrictive for no good
reason. We can safely ingore tha in arp_process. Let the packet
capture tools to check it, for monitoring purposes. There we can
see in tha to which hosts the packet was sent.

	As for the ARP broadcasts, we already have "arp_accept"
sysctl that prevents new entries to be added to cache. Can it
help for your ARP tests?

> +
> +		if (arp->ar_op == htons(ARPOP_REPLY) && !is_valid_garp) {
> +			net_warn_ratelimited("Drop ARP Reply in L2 BMC on %s\n",
> +					     dev->name);
> +			goto out_free_skb;
> +		}
> +		if (dev->addr_len == ETH_ALEN && tha &&
> +		    is_valid_ether_addr(tha) && !is_valid_garp) {
> +			net_warn_ratelimited("Drop unicast THA ARP Req in L2 BMC on %s\n",
> +					     dev->name);
> +			goto out_free_skb;
> +		}
> +	}

Regards

--
Julian Anastasov <ja@ssi.bg>

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

[Star Chang]

Hi Julian,

Thank you very much for the insightful review and for pointing out the RFC 826 and RFC 2002 references.

You are completely right on both points:
1. Per RFC 826, the Target Hardware Address (tha) in an ARP Request has no protocol meaning, and Linux updates neighbor entries using (sip, sha), never tha. Inspecting tha on ARP Requests was a fundamental mistake and would break legitimate devices that leave arbitrary/unicast addresses in tha.
2. In RFC 2002 (section 4.6), many real-world GARP reply implementations legitimately set tha to the broadcast address (ff:ff:ff:ff:ff:ff) since the announcement is broadcast to all hosts. Requiring tha == sha in our check was overly restrictive and would cause false-positive drops for legitimate GARP replies.

Regarding your question about arp_accept:
In our testing, arp_accept = 0 successfully prevents creating *new* neighbor entries from unsolicited broadcasts. However, in typical client scenarios, the victim station almost always already has an existing neighbor entry for its default gateway (i.e. n is not NULL in arp_process).

When n already exists, arp_accept is bypassed, and once the 1-second LOCKTIME window has passed, arp_process() calls:
    neigh_update(n, sha, state, NEIGH_UPDATE_F_OVERRIDE, 0);
which executes memcpy(&neigh->ha, lladdr, dev->addr_len) in __neigh_update(), overwriting the gateway's cached MAC address with the attacker's MAC.

In a Wi-Fi (Hole-196) scenario where clients share the GTK, an attacker cannot forge unicast frames directly to the victim, so they broadcast an unsolicited unicast ARP Reply (sip = gateway_ip, sha = attacker_mac, tip = victim_ip) over L2 broadcast (PACKET_BROADCAST).

Under standard networking behavior, a non-GARP ARP Reply is strictly meant to be delivered as an L2 unicast frame (PACKET_HOST) to the requester. The only legitimate reason an ARP Reply is ever sent over L2 broadcast is for Gratuitous ARP (sip == tip).

Based on your feedback, we plan to completely drop all checks on tha, leave ARP Requests entirely untouched, and strictly narrow the ARP defense to drop ARP Replies received over L2 BMC *only* if they are not Gratuitous ARP (sip != tip):

--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -791,32 +791,18 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
 		goto out_free_skb;
 
 	if ((skb->pkt_type == PACKET_BROADCAST ||
 	     skb->pkt_type == PACKET_MULTICAST) &&
 	    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
-		bool is_valid_garp = (sip == tip) && tha &&
-				     !memcmp(tha, sha, dev->addr_len);
-
-		if (arp->ar_op == htons(ARPOP_REPLY) && !is_valid_garp) {
-			net_warn_ratelimited("Drop ARP Reply in L2 BMC on %s\n",
+		/*
+		 * Standard ARP Replies are strictly unicast (PACKET_HOST).
+		 * An ARP Reply in an L2 broadcast frame with (sip != tip)
+		 * is an injected unicast reply. Legitimate GARP (sip == tip)
+		 * is preserved and defers to DROP_GRATUITOUS_ARP.
+		 * ARP Requests are left untouched per RFC 826.
+		 */
+		if (arp->ar_op == htons(ARPOP_REPLY) && sip != tip) {
+			net_warn_ratelimited("Drop non-GARP ARP Reply in L2 BMC on %s\n",
 					     dev->name);
 			goto out_free_skb;
 		}
-		if (dev->addr_len == ETH_ALEN && tha &&
-		    is_valid_ether_addr(tha) && !is_valid_garp) {
-			net_warn_ratelimited("Drop unicast THA ARP Req in L2 BMC on %s\n",
-					     dev->name);
-			goto out_free_skb;
-		}
 	}

With this approach:
1. ARP Requests are completely untouched (fully adhering to RFC 826).
2. Legitimate GARP announcements (sip == tip) for VRRP/HSRP router failovers are preserved regardless of what value they put in tha (respecting RFC 2002).
3. Injected unicast ARP Replies in L2 BMC (sip != tip) that poison existing gateway entries are dropped.

Does this sound like the right direction to you for v5?

Thanks again for your time, guidance, and expertise!

Best regards,
Star Chang

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

[Julian Anastasov]

	Hello,

On Wed, 28 Oct 2026, Star Chang wrote:

> Hi Julian,
> 
> Thank you very much for the insightful review and for pointing out the RFC 826 and RFC 2002 references.
> 
> You are completely right on both points:
> 1. Per RFC 826, the Target Hardware Address (tha) in an ARP Request has no protocol meaning, and Linux updates neighbor entries using (sip, sha), never tha. Inspecting tha on ARP Requests was a fundamental mistake and would break legitimate devices that leave arbitrary/unicast addresses in tha.
> 2. In RFC 2002 (section 4.6), many real-world GARP reply implementations legitimately set tha to the broadcast address (ff:ff:ff:ff:ff:ff) since the announcement is broadcast to all hosts. Requiring tha == sha in our check was overly restrictive and would cause false-positive drops for legitimate GARP replies.
> 
> Regarding your question about arp_accept:
> In our testing, arp_accept = 0 successfully prevents creating *new* neighbor entries from unsolicited broadcasts. However, in typical client scenarios, the victim station almost always already has an existing neighbor entry for its default gateway (i.e. n is not NULL in arp_process).
> 
> When n already exists, arp_accept is bypassed, and once the 1-second LOCKTIME window has passed, arp_process() calls:
>     neigh_update(n, sha, state, NEIGH_UPDATE_F_OVERRIDE, 0);
> which executes memcpy(&neigh->ha, lladdr, dev->addr_len) in __neigh_update(), overwriting the gateway's cached MAC address with the attacker's MAC.
> 
> In a Wi-Fi (Hole-196) scenario where clients share the GTK, an attacker cannot forge unicast frames directly to the victim, so they broadcast an unsolicited unicast ARP Reply (sip = gateway_ip, sha = attacker_mac, tip = victim_ip) over L2 broadcast (PACKET_BROADCAST).
> 
> Under standard networking behavior, a non-GARP ARP Reply is strictly meant to be delivered as an L2 unicast frame (PACKET_HOST) to the requester. The only legitimate reason an ARP Reply is ever sent over L2 broadcast is for Gratuitous ARP (sip == tip).
> 
> Based on your feedback, we plan to completely drop all checks on tha, leave ARP Requests entirely untouched, and strictly narrow the ARP defense to drop ARP Replies received over L2 BMC *only* if they are not Gratuitous ARP (sip != tip):

	Sashiko gives also example with RFC 3927 Section 2.5 and 4
where ARP packets (especially replies) with sip in 169.254.0.0/16
MUST be sent as broadcasts, so that boxes can detect that
their address is configured also on another host. So, may be
we should not drop sip in 169.254.0.0/16. But it is another open door.

	As for the received broadcast requests, it is still possible
to send replies where needed but to skip the step where we use sha
to update the cache for sip. We can set some flag 'cacheupd' early
and later to check it. The result will be:

- ARP Probes: replied as usually (there is no cache update for sip 0)
- n = neigh_event_ns(): avoided but replies are sent if !dont_send
- do not lookup for n, jump before the lookup
- ARP Announce (GARP): ignored, sorry, the attacker announces
new sha for GWIP

> 
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -791,32 +791,18 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
>  	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
>  		goto out_free_skb;
>  
>  	if ((skb->pkt_type == PACKET_BROADCAST ||
>  	     skb->pkt_type == PACKET_MULTICAST) &&
>  	    IN_DEV_ORCONF(in_dev, DROP_UNICAST_IN_L2_MULTICAST)) {
> -		bool is_valid_garp = (sip == tip) && tha &&
> -				     !memcmp(tha, sha, dev->addr_len);
> -
> -		if (arp->ar_op == htons(ARPOP_REPLY) && !is_valid_garp) {
> -			net_warn_ratelimited("Drop ARP Reply in L2 BMC on %s\n",
> +		/*
> +		 * Standard ARP Replies are strictly unicast (PACKET_HOST).
> +		 * An ARP Reply in an L2 broadcast frame with (sip != tip)
> +		 * is an injected unicast reply. Legitimate GARP (sip == tip)
> +		 * is preserved and defers to DROP_GRATUITOUS_ARP.
> +		 * ARP Requests are left untouched per RFC 826.
> +		 */
> +		if (arp->ar_op == htons(ARPOP_REPLY) && sip != tip) {
> +			net_warn_ratelimited("Drop non-GARP ARP Reply in L2 BMC on %s\n",
>  					     dev->name);
>  			goto out_free_skb;
>  		}
> -		if (dev->addr_len == ETH_ALEN && tha &&
> -		    is_valid_ether_addr(tha) && !is_valid_garp) {
> -			net_warn_ratelimited("Drop unicast THA ARP Req in L2 BMC on %s\n",
> -					     dev->name);
> -			goto out_free_skb;
> -		}
>  	}
> 
> With this approach:
> 1. ARP Requests are completely untouched (fully adhering to RFC 826).

	See above

> 2. Legitimate GARP announcements (sip == tip) for VRRP/HSRP router failovers are preserved regardless of what value they put in tha (respecting RFC 2002).

	Drop them. Or leave it to DROP_GRATUITOUS_ARP to decide,
it is per iface too. There should be no chance to update cache
from broadcasts.

> 3. Injected unicast ARP Replies in L2 BMC (sip != tip) that poison existing gateway entries are dropped.
> 
> Does this sound like the right direction to you for v5?

	Yep. But not sure for the IP part...

> Thanks again for your time, guidance, and expertise!
> 
> Best regards,
> Star Chang

Regards

--
Julian Anastasov <ja@ssi.bg>