CVE-2026-16515: dos in zephyrproject zephyr
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.
AI Analysis
Technical Summary
The vulnerability exists because net_icmpv6_send_error() in Zephyr's ICMPv6 implementation only enforces one of three suppression rules from RFC 4443 section 2.4. It fails to check if the source address of the triggering packet is unique to a single node or if the packet was sent to a multicast destination, except for specific exceptions. An attacker can exploit this by sending crafted IPv6 packets with spoofed source addresses to cause Zephyr nodes to emit amplified ICMPv6 Parameter Problem messages or multicast ICMPv6 errors, resulting in denial-of-service conditions on the link. The fix involves adding the missing suppression checks before reply packets are allocated, preserving necessary exceptions.
Potential Impact
The vulnerability allows an unauthenticated attacker on the same link to cause denial of service by flooding the network with ICMPv6 error messages. This degrades availability of the shared link and the victim of reflected traffic. The attack can amplify traffic proportional to the number of Zephyr nodes on the link and can cause multicast flooding, especially impacting constrained mesh networks such as 802.15.4/Thread. There is no memory safety impact, only availability degradation.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix adds suppression checks in net_icmpv6_send_error() to comply with RFC 4443. Until a patch is applied, network administrators should consider network-level controls to limit spoofed IPv6 traffic or multicast abuse on local links.
CVE-2026-16515: dos in zephyrproject zephyr
Description
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.
CVSS v3.1
Score 4.7medium
Affected software
zephyrproject
zephyr
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability exists because net_icmpv6_send_error() in Zephyr's ICMPv6 implementation only enforces one of three suppression rules from RFC 4443 section 2.4. It fails to check if the source address of the triggering packet is unique to a single node or if the packet was sent to a multicast destination, except for specific exceptions. An attacker can exploit this by sending crafted IPv6 packets with spoofed source addresses to cause Zephyr nodes to emit amplified ICMPv6 Parameter Problem messages or multicast ICMPv6 errors, resulting in denial-of-service conditions on the link. The fix involves adding the missing suppression checks before reply packets are allocated, preserving necessary exceptions.
Potential Impact
The vulnerability allows an unauthenticated attacker on the same link to cause denial of service by flooding the network with ICMPv6 error messages. This degrades availability of the shared link and the victim of reflected traffic. The attack can amplify traffic proportional to the number of Zephyr nodes on the link and can cause multicast flooding, especially impacting constrained mesh networks such as 802.15.4/Thread. There is no memory safety impact, only availability degradation.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix adds suppression checks in net_icmpv6_send_error() to comply with RFC 4443. Until a patch is applied, network administrators should consider network-level controls to limit spoofed IPv6 traffic or multicast abuse on local links.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-07-21T21:43:00.776Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6aad678855bf5e2cf53e1040
Added to database: 09/18/2026, 16:32:08 UTC
Last enriched: 09/18/2026, 16:46:45 UTC
Last updated: 09/19/2026, 01:38:09 UTC
Views: 10
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.