CVE-2026-10639: Zephyr IPv4 Use-After-Free in ICMP Echo Reply Statistics

Technical summary

The vulnerability exists in icmpv4_handle_echo_request() within subsys/net/ip/icmpv4.c. The function builds an ICMP echo-reply packet and passes it to net_try_send_data(), which transfers ownership to the TX path. Per the documented contract in net_core.c, the packet structure becomes invalid after this call and must not be accessed. However, the code then unconditionally calls net_stats_update_icmp_sent(net_pkt_iface(reply)), reading the reply->iface field from a packet that may have already been unreferenced and returned to the kernel's memory slab. Under CONFIG_NET_STATISTICS_PER_INTERFACE, this becomes a write through a potentially stale pointer, incrementing a statistics counter via a recycled or reallocated memory address. The companion function net_icmpv4_send_error() does not have this defect because it reads from the caller-owned received packet (orig), which remains live. The vulnerability has existed since Zephyr v1.14 (2019) through at least v4.4.0.

Business impact

A remotely triggered crash via DoS affects availability of Zephyr-based IoT and embedded devices. Corruption of per-interface statistics can mask network diagnostics and monitoring, making it difficult to detect legitimate traffic anomalies or troubleshoot connectivity issues. In safety-critical or industrial control environments, unpredictable crashes undermine reliability and uptime guarantees. The low barrier to exploitation (any remote ICMP echo request) and unauthenticated access path mean that devices on open networks or those accepting external packets are at continuous risk. Organizations relying on Zephyr for mission-critical edge or IoT deployments should prioritize patching to restore deterministic behavior and accurate telemetry.

Affected systems

Zephyr versions from v1.14 (released 2019) through v4.4.0 are affected. The vulnerability is only reachable if both CONFIG_NET_STATISTICS_ICMP and Zephyr's native IPv4 stack are enabled in the kernel configuration. Devices that have disabled these configuration flags are not vulnerable. Zephyr is widely used in IoT, smart home, industrial IoT, wearables, and embedded systems that require a lightweight real-time kernel. Any Zephyr-based product with IPv4 networking and statistics collection enabled and exposed to untrusted networks is potentially vulnerable.

Exploitability

Exploitation requires sending ICMP echo requests (ping) to a Zephyr device, which is a standard, unauthenticated network operation. No credentials, special privileges, or user interaction are needed. The vulnerability is a timing race: the attacker must cause the packet memory to be recycled by the kernel's memory allocator between when net_try_send_data() returns and when the post-send stats line executes. This race window is narrow but likely to occur under moderate ICMP traffic or in scenarios where the kernel experiences memory pressure and rapidly reuses slabs. Success is probabilistic rather than deterministic, but repeated pings increase the likelihood of hitting the race condition. The resulting corruption or crash is most likely to manifest as invalid statistics, silent data corruption, or a kernel panic, rather than memory disclosure or code execution.

Remediation

The fix involves caching the interface pointer from the received packet (which remains caller-owned and valid) before calling net_try_send_data(), then using the cached pointer for post-send statistics updates instead of dereferencing the freed reply packet. This eliminates the use-after-free read and write. Verification of the fix requires checking that net_pkt_iface(reply) is no longer accessed after the send handoff. Organizations should upgrade to the patched Zephyr version once released. As an interim mitigation, disabling CONFIG_NET_STATISTICS_ICMP or CONFIG_NET_STATISTICS_PER_INTERFACE in the kernel configuration will prevent the vulnerable code path from executing, though this sacrifices per-interface diagnostic telemetry.

Patch guidance

Monitor Zephyr project releases and security advisories for a patched version addressing this use-after-free. The fix is likely to land in a maintenance release (e.g., v4.4.1 or v4.5.0) or as a backport to long-term-support branches. Verify the patch against the official Zephyr repository commit history and release notes. Organizations managing fleets of Zephyr devices should establish a process to verify patch availability, test the patch in a staging environment to ensure no regressions in network or statistics functionality, and then roll out to production. For devices in the field with over-the-air update capability, plan for timely deployment; for fixed devices, assess the business risk and prioritize patching of exposed or critical systems first.

Detection guidance

Monitor syslog and kernel logs for ICMP-related crashes, kernel panics, or invalid memory access warnings. Watch for unexplained resets or watchdog timeouts correlated with elevated ping traffic or network scanning. Inspect per-interface statistics counters for anomalies such as negative values, extreme jumps, or inconsistencies that may indicate corruption from the use-after-free write. Network telemetry tools that collect interface statistics from devices may reveal invalid or impossible counter values. During testing or validation, enable kernel debugging (e.g., CONFIG_DEBUG_MEMORY or kernel address sanitizers if available in Zephyr) to catch the use-after-free access. Note that exploitation is probabilistic, so absence of a crash does not guarantee the device is unaffected; corruption may accumulate silently until a more severe event occurs.

Why prioritize this

Although the CVSS score is MEDIUM (4.8), the combination of unauthenticated remote triggering, low complexity, and presence in the default IPv4 networking path elevates practical risk. Any Zephyr device accepting external packets is continuously exposed without user action or special configuration. The vulnerability has been present for over five years, likely affecting legacy and production deployments. Devices in safety-critical or high-availability roles should be patched immediately; others should be scheduled for patching as part of the next maintenance window. The probabilistic nature of exploitation means that large fleets will likely experience incidents; early patching limits exposure across the inventory.

Risk score, explained

The CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L score of 4.8 MEDIUM reflects: network-accessible vector (AV:N), high attack complexity (AC:H) due to timing-race dependency, no privileges or user interaction required (PR:N, UI:N), integrity impact from potential statistics corruption or wild writes (I:L), and availability impact from DoS via crash (A:L). The AC:H reflects that successful exploitation depends on memory allocation timing, not on bypassing cryptography or defeating a strong mitigation. However, in practice, repeated ICMP traffic from multiple sources or under load increases the probability of hitting the race, partially reducing the effective complexity.

Frequently asked questions