CVE-2026-10646: Zephyr DNS Use-After-Return Vulnerability in getaddrinfo()

Technical summary

The vulnerability exists in subsys/net/lib/sockets/getaddrinfo.c where the socket layer waits on a semaphore with a timeout slightly longer than the DNS resolver's per-query timeout. When the semaphore wait times out (returning -EAGAIN)—which can occur due to workqueue delays or multi-retry configurations where CONFIG_NET_SOCKETS_DNS_TIMEOUT exceeds CONFIG_NET_SOCKETS_DNS_BACKOFF_INTERVAL—the code retries the DNS query without cancelling the in-flight query or resetting the semaphore. The struct getaddrinfo_state (ai_state) pointer, passed as user_data to the async resolver, remains registered as a callback with a stack address. The ai_state->dns_id is overwritten, making the stale query uncancellable. When a DNS response arrives and matches the 16-bit transaction ID (via dispatcher_cb() or dns_read()), or when the resolver's delayed timeout work fires, dns_resolve_cb() executes against the now-invalid stack frame, writing to state->status, state->idx, state->ai_arr[], and calling k_sem_give() through a use-after-return pointer. The 16-bit transaction ID is spoofable and replayable by network-positioned attackers. The fix cancels the timed-out query by name and type before retry and resets the semaphore to eliminate the stale callback path.

Business impact

This vulnerability enables network-based denial of service and potential memory corruption on Zephyr-based IoT and embedded devices. An attacker with network access (on-path or off-path via ID spoofing) can trigger crashes by sending crafted or replayed DNS responses, disrupting device availability. In memory-constrained embedded environments, the corruption could enable escalation to code execution or system compromise. For organizations deploying Zephyr in critical IoT applications, industrial control, or safety-critical systems, this represents a significant availability and integrity risk that requires prompt remediation.

Affected systems

Zephyr RTOS versions 4.0.0 through 4.4.0 are affected. Specifically, the getaddrinfo() implementation in the BSD sockets subsystem is vulnerable when DNS resolution with timeouts and retries is active. Systems using Zephyr's socket-based DNS resolution in multi-threaded or workqueue-contended environments are at higher risk. Devices relying on DNS for any network service (HTTP, MQTT, CoAP, etc.) are exposed if they cannot isolate DNS queries or rely on external DNS resolvers.

Exploitability

Exploitability is moderate to high. An attacker needs network access to the target device (or the ability to inject traffic on its network path), but does not require elevated privileges, user interaction, or special configuration beyond basic DNS usage. The 16-bit transaction ID is small enough that an attacker can brute-force or replay captured IDs, especially in high-traffic scenarios. The attack is reliable if the attacker can observe or predict DNS query patterns. Denial of service via sustained DNS response injection is straightforward and requires minimal resources. Memory corruption exploitation is harder but not implausible on systems with predictable stack layouts.

Remediation

Users must upgrade to a patched version of Zephyr that includes the fix to getaddrinfo.c (verify exact version against the official Zephyr security advisory). The patch cancels timed-out queries by name and type before retry and resets the semaphore. As an interim mitigation, organizations can reduce DNS timeout and retry configurations to minimize the window, or route DNS through a trusted, rate-limited proxy that filters malformed responses. However, these are workarounds; upgrading is the definitive fix.

Patch guidance

Monitor the Zephyr project's official security advisories for release of patched versions addressing CVE-2026-10646. Once available, patch versions should be integrated into your build and deployed across all affected Zephyr-based devices. Test patches in a non-production environment, particularly in high-workqueue-contention scenarios, to confirm stability. If devices cannot be patched immediately, implement network segmentation and egress filtering to restrict DNS traffic to trusted, monitored resolvers.

Detection guidance

Look for repeated DNS timeouts and retries in system logs, followed by unexpected crashes or memory corruption errors (hard faults, segmentation faults, or heap corruption warnings). Monitor for anomalies in DNS response patterns (duplicate transaction IDs, out-of-sequence responses). Implement network-level monitoring for DNS traffic to the affected devices; watch for reply flooding or replay of previously observed query IDs. Enable Zephyr kernel logging at DEBUG level for DNS and socket subsystems to capture evidence of stale callbacks or semaphore anomalies. Memory corruption detection tools (ASAN, stack canaries) may catch the write-through-stale-pointer, but typically only in post-mortem analysis after a crash.

Why prioritize this

With a CVSS score of 7.4 (HIGH) and network-exploitability, this warrants high-priority patching. The vulnerability does not require user interaction or special privileges, and an attacker can trigger it remotely by injecting spoofed DNS responses. While memory corruption exploitation is not trivial, denial of service is immediate and impactful. Zephyr's deployment in IoT and critical embedded systems amplifies the business risk. Organizations using affected Zephyr versions should prioritize patch assessment and deployment within their standard critical vulnerability response window (typically 1–2 weeks).

Risk score, explained

The CVSS 3.1 score of 7.4 reflects HIGH severity: a network vector (AV:N), attack complexity of high (AC:H—requires timing/workqueue conditions or multi-retry configuration to trigger), no privileges or user interaction required, and impacts both integrity (I:H—memory corruption) and availability (A:H—crash/DoS). Confidentiality is not impacted (C:N). The AC:H rating acknowledges that the vulnerability requires specific conditions (workqueue delay or multi-retry setup) to manifest, but these are common in real Zephyr deployments. The network vector and spoofability of the 16-bit DNS ID elevate exploitability despite AC:H.

Frequently asked questions