Executive brief
Zephyr's IPv6 network stack fails to properly suppress ICMPv6 error messages in two scenarios: when responses would be sent to multicast addresses or when the triggering packet has a multicast source address. An attacker on the local network can exploit this to create amplification attacks against victims on the same link or mesh network, causing service degradation and enabling address spoofing. No configuration changes are required, and constrained networks like Thread/802.15.4 are particularly vulnerable due to hop-by-hop multicast flooding.
Technical details
The vulnerability lies in net_icmpv6_send_error() in subsys/net/ip/icmpv6.c, which implements only one of three RFC 4443 section 2.4 suppression rules: it prevents ICMPv6 errors from answering ICMPv6 errors, but fails to check whether the triggering packet was sent to a multicast destination (rule e.3, except Packet Too Big and Parameter Problem Code 2) or had a multicast source address (rule e.6). An unauthenticated attacker on the link can send a spoofed packet to ff02::1 with an unrecognized next-header value, causing all nodes to reflect an ICMPv6 Parameter Problem to the spoofed victim (N-way amplification), or send a unicast packet with a multicast source, causing the node to transmit its error to that multicast address (link flooding). The fix adds both suppression checks in the single error-sending function, preserving RFC exceptions for Packet Too Big and Parameter Problem Code 2. IPv4's counterpart net_icmpv4_send_error() has similar gaps.
Affected products
- Zephyr Zephyr RTOS affected versions prior to fix
Timeline
- 2026-09-18: disclosed
- 2026-09-18: advisory