CVE-2026-16515 in Zephyr
Summary
by MITRE • 09/18/2026
net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet's source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none.
An unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim — a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required.
The impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it.
The fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability resides within the ICMPv6 error handling implementation of the Zephyr operating system, specifically in the net_icmpv6_send_error function located in subsys/net/ip/icmpv6.c. This component is responsible for generating various ICMPv6 error messages such as parameter problems, packet too big notifications, and port unreachable alerts when a node encounters issues processing incoming IPv6 packets. The core technical flaw stems from an incomplete implementation of the suppression rules defined in RFC 4443 section 2.4. While the code correctly adheres to the rule prohibiting ICMPv6 error messages as responses to other ICMPv6 errors, it fails to enforce two critical additional suppressions mandated by the standard. First, it does not verify whether the source address of the triggering packet identifies a single node rather than a multicast or anycast group. Second, it neglects to check if the original packet was destined for a multicast address, with exceptions only made for Packet Too Big messages and Parameter Problem Code 2 notifications. This oversight means that under specific conditions, nodes will generate ICMPv6 error responses in scenarios where protocol compliance strictly forbids them.
The operational impact of this deficiency is significant, primarily manifesting as degraded availability through denial-of-service attacks leveraging both reflection and amplification techniques. An unauthenticated attacker positioned on the same network link can exploit these missing checks to launch two distinct attack vectors without requiring any special configuration or privileges. In the first vector, an attacker sends a single IPv6 packet with an unrecognized next-header value directed at the link-local all-nodes multicast address ff02::1 while spoofing the source IP address to that of a victim. Because ipv6_input() accepts packets addressed to ff02::1 unconditionally and does not reject multicast source addresses, every Zephyr node on the local network segment will process this packet and subsequently emit an ICMPv6 Parameter Problem message directed at the spoofed victim. This creates a reflector scenario where the amplification factor is equal to the total number of nodes present on the link, effectively overwhelming the target with traffic generated by innocent third parties.
The second exploitation vector involves sending a unicast packet that contains a multicast address as its source IP field. When such a malformed or non-compliant packet triggers an ICMPv6 error condition within Zephyr, the system transmits the resulting error message to the destination of the original packet rather than suppressing it due to the invalid source characteristics. This transforms a single unicast request into a flood of multicast frames across the link, consuming bandwidth and processing resources on all listening nodes. The impact is particularly severe in constrained mesh networks such as those based on IEEE 802.15.4 or Thread protocols, where link-local multicast traffic is flooded hop-by-hop throughout the network topology. This amplification effect can quickly saturate low-bandwidth wireless links, leading to widespread connectivity issues for all devices within range.
From a security classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write in terms of protocol state violation and more accurately reflects CWE-20: Improper Input Validation regarding the failure to validate source address types before generating responses. In the context of the MITRE ATT&CK framework, this behavior facilitates techniques associated with T1498: Network Denial of Service, specifically leveraging reflection and amplification mechanisms similar to those seen in DNS or NTP-based attacks but applied at the network layer using ICMPv6. The absence of memory-safety consequences is notable; the error packets generated are well-formed and do not cause buffer overflows or crashes directly. However, the resource exhaustion caused by excessive packet generation constitutes a serious availability risk that undermines the reliability of the IP stack in production environments.
The remediation strategy implemented addresses these gaps at the single choke point within net_icmpv6_send_error(), ensuring that suppression checks are performed before any reply packet is allocated or transmitted. The fix explicitly validates whether the triggering packet originated from a multicast source and whether it was destined for a multicast address, thereby enforcing RFC 4443 compliance across all error paths including extension-header errors, unknown next-header notifications, and fragmentation issues in ipv6.c and ipv6_fragment.c. It is important to note that while this patch resolves the issue for IPv6, the corresponding IPv4 implementation net_icmpv4_send_error() retains a similar gap by only checking for broadcast destinations and lacking equivalent safeguards against multicast sources or non-unique source addresses. System administrators should be aware of this asymmetry and consider applying analogous mitigations to IPv4 processing paths if they are present in their specific deployment configurations, although the immediate risk is concentrated on the IPv6 stack described here.