CVE-2026-10638: Zephyr ICMPv6 Use-After-Free Denial of Service

Technical summary

The vulnerability resides in subsys/net/ip/icmpv6.c, where icmpv6_handle_echo_request() and net_icmpv6_send_error() call net_pkt_iface() on outbound packets after those packets have been passed to net_try_send_data(). The send path (net_try_send_data → net_if_tx) unreferences and may synchronously free the packet (when CONFIG_NET_TC_TX_COUNT == 0) or permit asynchronous freeing by the driver/L2 layer. This creates a use-after-free read on net_pkt_iface(). When CONFIG_NET_STATISTICS_PER_INTERFACE is enabled, the stale interface pointer is dereferenced and written to (iface->stats.icmp.sent++), escalating the vulnerability to a controlled write through an attacker-influenced pointer. The core stack (net_core.c) already documents this hazard and caches the interface pointer before sending; the ICMPv6 callers did not follow this pattern. A parallel vulnerability exists in ICMPv4 (addressed by commit 86e21665d46).

Business impact

Embedded and IoT systems running Zephyr with IPv6 enabled are vulnerable to remote denial of service. An unauthenticated attacker can crash the device or potentially corrupt kernel memory without any authentication, network credentials, or local access. For deployments in safety-critical or production environments (industrial control, medical devices, edge gateways), this creates both availability and integrity risks. The attack surface is large: any exposed IPv6 interface accepts ICMPv6 packets by default. Recovery requires device restart, incurring downtime proportional to the device's role in the system.

Affected systems

Zephyr project versions approximately 4.2.0 through 4.4.0 with CONFIG_NET_NATIVE_IPV6 enabled and an exposed IPv6 network interface. Systems with CONFIG_NET_STATISTICS_PER_INTERFACE enabled face elevated risk (potential memory corruption write), while those without it experience use-after-free reads (memory disclosure, instability, crash). Verify your Zephyr version and build configuration (menuconfig or prj.conf) for both IPv6 and statistics settings.

Exploitability

Exploitability is straightforward: no authentication, privilege escalation, or user interaction required. An unauthenticated remote attacker sends ordinary ICMPv6 packets (ping/Echo Request, or packets triggering IPv6 error responses such as unknown next header or destination unreachable) over an IPv6-enabled network. The vulnerability is triggered synchronously when no TX queue is configured and may be asynchronous otherwise. The barrier to exploitation is low—standard networking tools can craft the necessary packets. However, the actual impact depends on the device's role and whether memory corruption can be reliably weaponized; denial of service via crash is the primary practical outcome.

Remediation

Patch to a Zephyr version containing the fix (verify against the official Zephyr advisory for exact version numbers). The fix caches the interface pointer before sending the packet and uses the cached value for all subsequent statistics updates. Interim mitigations include disabling IPv6 if not required (CONFIG_NET_NATIVE_IPV6=n), disabling statistics per interface (CONFIG_NET_STATISTICS_PER_INTERFACE=n), or restricting IPv6 traffic at the network boundary. However, patching is the only complete solution.

Patch guidance

Consult the official Zephyr project security advisory and commit history for the exact patched version. The fix is described as caching the interface pointer before sending and using it for all statistics updates. Apply patches to development boards and production devices in a staged manner, testing IPv6 and ICMPv6 functionality after upgrade to confirm no regressions. Verify your build configuration includes the patches and that CONFIG_NET_NATIVE_IPV6 is still required for your use case.

Detection guidance

Monitor for unexpected kernel crashes or panics on Zephyr devices receiving IPv6 traffic, particularly spikes in ICMPv6 traffic (Echo Requests, time-exceeded, or destination-unreachable messages). Memory corruption signatures (heap corruption warnings, stack overflow messages, or unaligned pointer dereferences in network code) may appear in device logs. Network-side detection is limited without deep packet inspection; consider blocking unexpected ICMPv6 traffic at network ingress if the application does not require it. If possible, enable kernel debugging and memory poisoning (KASAN) on a test device to catch the flaw in development.

Why prioritize this

Although assigned CVSS 5.9 (Medium), this vulnerability merits higher prioritization for embedded and IoT deployments. The attack surface is large (any IPv6 interface), the barrier to exploitation is trivial (no credentials, standard packets), and the impact is immediate (denial of service). For safety-critical or production systems, memory corruption risk (when CONFIG_NET_STATISTICS_PER_INTERFACE is enabled) elevates concern. Zephyr's typical deployment in long-lived embedded devices means patching delays compound risk. Organizations with Zephyr-based systems exposed to untrusted networks should prioritize rapidly.

Risk score, explained

CVSS 5.9 reflects a remotely triggered, unauthenticated denial-of-service vulnerability with no attack complexity requirements beyond packet crafting (AC:H reflects only the synchronicity conditions). The score reflects the flaw's severity (crash via use-after-free) while stopping short of critical due to the lack of confidentiality impact in the base case and the controlled write's dependency on specific configuration (CONFIG_NET_STATISTICS_PER_INTERFACE). However, risk is context-dependent: highly networked or safety-critical deployments should treat this as high priority; isolated or IoT devices may tolerate slightly longer patch cycles if other controls exist.

Frequently asked questions