CVE-2026-10640: Zephyr IPv6 Neighbor Discovery Use-After-Free Vulnerability

Technical summary

The vulnerability exists in three IPv6 Neighbor Discovery transmission functions in subsys/net/ip/ipv6_nbr.c (net_ipv6_send_na, net_ipv6_send_ns, net_ipv6_send_rs). These functions call net_send_data() to transmit packets, which transfers ownership to the L2 driver layer. The driver then dereferences the packet and releases it via net_pkt_unref(). After net_send_data() returns successfully, the vulnerable code calls net_pkt_iface(pkt) to retrieve the interface pointer for updating per-interface ICMP statistics. However, if the packet's reference count is 1 at transmission time, the slab block can be freed before the statistics code executes. The subsequent dereference of the freed pointer (pkt->iface) causes a use-after-free (CWE-416). When CONFIG_NET_STATISTICS_PER_INTERFACE is enabled, the code then dereferences that loaded pointer to increment iface->stats.icmp.sent, potentially writing to attacker-influenced or unrelated memory. Devices without per-interface statistics enabled are not vulnerable to the memory-safety aspect, as they only update a global counter.

Business impact

For deployments using Zephyr in IPv6-enabled IoT or embedded systems, this vulnerability introduces reliability and availability risks. A nearby attacker can remotely trigger denial of service by crashing Zephyr devices via malformed ICMPv6 packets, disrupting critical operations without authentication. In environments where per-interface statistics are enabled, the memory corruption aspect could lead to unpredictable device behavior, data corruption, or escalated compromise. Organizations relying on Zephyr for network-facing applications should treat this as a patch priority to prevent operational disruptions and maintain system integrity.

Affected systems

Zephyr RTOS versions 3.3.0 through 4.4.0 are affected. The vulnerability is only exploitable when native IPv6 is enabled on a Zephyr device. Exploitation requires network adjacency (same link-local segment) and does not require authentication or user interaction. Systems running Zephyr without IPv6 enabled, or with older versions prior to 3.3.0, are not affected by this specific flaw.

Exploitability

The vulnerability is relatively straightforward to exploit. An unauthenticated attacker on the same network link can send crafted ICMPv6 Neighbor Solicitation packets to trigger the vulnerable Neighbor Advertisement code path (handle_ns_input -> net_ipv6_send_na). No authentication, user interaction, or special privileges are required. The CVSS score of 4.2 (MEDIUM) reflects local network access requirements and the fact that impacts are limited to integrity and availability; however, the exploitation barrier is low. The primary obstacle is network adjacency—the attacker must be able to send packets to the same IPv6 link as the target device.

Remediation

Upgrade to a patched version of Zephyr that addresses this issue. The fix involves refactoring the vulnerable functions to use the already-available interface argument instead of dereferencing the packet pointer after transmission. Verify the specific patched version number against Zephyr's official security advisory. As an interim mitigation for environments unable to patch immediately, disable per-interface statistics (CONFIG_NET_STATISTICS_PER_INTERFACE) if not required, which eliminates the memory-corruption aspect, though the use-after-free technically remains. Additionally, network segmentation and access controls restricting ICMPv6 traffic can reduce exposure in defense-in-depth strategies.

Patch guidance

Check Zephyr's official security advisories and release notes to identify the patched version (expected to be 4.5.0 or later, depending on the release schedule). Update your Zephyr installation to the patched version and rebuild affected firmware. Test the patched firmware in a non-production environment to verify functionality, particularly IPv6 Neighbor Discovery behavior and any statistics collection routines. For devices already deployed, plan a firmware update cycle and validate that the patch does not introduce regressions in your specific use case.

Detection guidance

Monitor for unexpected crashes or reboots in Zephyr devices with IPv6 enabled. Enable verbose logging for IPv6 Neighbor Discovery and ICMP processing to detect patterns of malformed ICMPv6 Neighbor Solicitations arriving from unexpected sources. If you have access to packet captures on the network link, look for unusually high rates of ICMPv6 NS packets sent to your Zephyr devices. Heap corruption or memory-related faults logged by the Zephyr kernel may indicate active exploitation. Organizations running Zephyr with CONFIG_NET_STATISTICS_PER_INTERFACE enabled should prioritize monitoring for these signals.

Why prioritize this

Although the CVSS score is 4.2 (MEDIUM), this vulnerability merits prioritization for several reasons: (1) It requires no authentication and affects any IPv6-enabled Zephyr device on a network link; (2) It causes denial of service with a single malformed packet, disrupting device availability; (3) Potential memory corruption could lead to unpredictable behavior or cascading failures in multi-device deployments; (4) The affected version range (3.3.0–4.4.0) likely covers significant installed bases. Prioritize patching for Zephyr devices in production environments, particularly those handling critical functions or operating in environments with untrusted network adjacency.

Risk score, explained

The CVSS 3.1 score of 4.2 (MEDIUM) reflects the following: Attack Vector (Adjacent) acknowledges the need for network presence on the same link; Attack Complexity (High) accounts for race condition variability and the requirement that CONFIG_NET_STATISTICS_PER_INTERFACE be enabled for full impact; Privileges Required (None) and User Interaction (None) reflect the unauthenticated, spontaneous nature of exploitation. Integrity (Low) and Availability (Low) reflect the unpredictable memory corruption and crash scenarios. The score does not fully capture the operational risk—a single packet crashing an IoT device has high business impact despite the technical severity rating. Organizations should consider context (device role, network exposure, statistics configuration) when determining their own remediation timeline.

Frequently asked questions