CVE-2026-10646: Zephyr RTOS DNS Memory Corruption

Quick impact assessment for defenders

The main security takeaway is that this is not just a benign logic bug. The vulnerability sits in a network-facing code path and involves asynchronous callback execution against expired stack memory. Even when exact exploitation conditions are not fully documented publicly, memory corruption bugs in network processing paths should be treated seriously in embedded environments because they often manifest first as intermittent crashes, resolver instability, or unexplained resets.

The available source material supports denial-of-service and undefined behavior as realistic outcomes. It does not provide enough detail to responsibly claim full remote code execution, so defenders should avoid overstating the risk. Still, if your device accepts or initiates DNS traffic and uses vulnerable Zephyr code paths, the right working assumption is that a network-triggerable memory corruption condition exists and patching should be prioritized accordingly.

Affected products and versions

The affected product is Zephyr RTOS. What is confirmed from the available source material is that the flaw exists in pre-fix Zephyr code handling getaddrinfo() asynchronous DNS resolution. The NVD entry and upstream references confirm the component and the existence of a fix commit.

The exact affected version range and the fixed release version number were not verifiable from the source material provided here. That matters because version precision is important for fleet triage, but inventing ranges would be misleading. Defenders should therefore assume that any Zephyr build containing the vulnerable pre-fix implementation in subsys/net/lib/sockets/getaddrinfo.c is affected until they verify inclusion of the upstream fix commit cd27da58eedb8d0fe380dd340b81ca5afa35de45 or a vendor release note explicitly stating the patch is included.

Technical Notes

You can check whether your Zephyr source tree includes the fix commit if you maintain source-based builds:

git -C /path/to/zephyr rev-parse --verify cd27da58eedb8d0fe380dd340b81ca5afa35de45

If the commit is present, Git will return the commit ID. If not, it will error. You can also inspect the affected file history:

git -C /path/to/zephyr log --oneline -- subsys/net/lib/sockets/getaddrinfo.c

For downstream SDKs or vendor firmware, verify the bundled Zephyr revision:

git -C /path/to/your/project submodule status
west list

If your vendor does not disclose the Zephyr base revision, assume exposure until they confirm patch status.

Technical root cause

The root cause is a mismatch between stack object lifetime and asynchronous callback lifetime. getaddrinfo() creates a stack-allocated state object, often described in the advisory context as struct getaddrinfo_state ai_state, and passes its pointer as user_data to the asynchronous DNS resolver. That pattern is safe only if all callbacks are guaranteed to complete before the function returns or if outstanding operations are canceled reliably.

The bug appears when the socket layer waits on a semaphore and times out with -EAGAIN, then retries the request without canceling the prior query and without resetting synchronization state properly. The earlier resolver slot remains active, but the tracking field for cancellation is overwritten on retry. Later, either a delayed DNS response or delayed resolver timeout work triggers dns_resolve_cb() using the stale pointer. At that point, the callback operates on an out-of-scope stack frame, creating memory corruption.

Technical Notes

The conditions explicitly called out in the available description include workqueue contention and a documented multi-retry configuration where:

CONFIG_NET_SOCKETS_DNS_TIMEOUT > CONFIG_NET_SOCKETS_DNS_BACKOFF_INTERVAL

That means this is not purely academic. Timing-related failures become more plausible when embedded systems are busy, under load, or configured for retries. In constrained RTOS environments, delayed workqueue execution is common enough that defenders should not dismiss this as unreachable.

A simplified conceptual flow looks like this:

struct getaddrinfo_state ai_state;   // stack object
dns_id = dns_get_addr_info(..., dns_resolve_cb, &ai_state);

ret = k_sem_take(&ai_state.sem, timeout);
if (ret == -EAGAIN) {
    // vulnerable behavior before fix:
    // retry without canceling previous query
    // stale callback still references &ai_state
    goto again;
}

// function returns, ai_state goes out of scope
// delayed callback later runs against invalid stack memory

Exploitation status and attacker considerations

As of 2026-06-28, there is no verified evidence from the provided primary sources that CVE-2026-10646 is being exploited in the wild. It is not listed in the CISA Known Exploited Vulnerabilities catalog, which means there is no CISA-confirmed active exploitation signal at this time. That is useful context for prioritization, but it should not be read as a guarantee of safety.

There is also no verified public proof-of-concept in the materials available here. The known references point to the NVD entry, the upstream fix commit, and the GitHub Security Advisory. In the absence of a public PoC, defenders should still assume reproductions are possible for capable researchers because the bug mechanics are clearly described: timeout handling, retry logic, async DNS callbacks, and stale stack context.

Prioritization guidance for SMBs and embedded teams

If you are an SMB using third-party appliances built on Zephyr, the most important action is to ask vendors whether their firmware includes the fix commit or an equivalent patched Zephyr release. Because exact version ranges were not verifiable from the source material here, vendor attestation is essential. Ask for the embedded Zephyr revision, patch inclusion status, and estimated firmware release date.

For internal engineering teams building on Zephyr directly, treat this as a high-priority networking patch, especially if your product performs DNS lookups during startup, cloud registration, MQTT bootstrap, OTA workflows, or dynamic service discovery. Those are the kinds of real-world operations that can repeatedly invoke getaddrinfo() and increase the chances of hitting retry and timeout paths.

Bottom line

CVE-2026-10646 is a high-severity Zephyr RTOS memory-safety flaw in getaddrinfo() asynchronous DNS handling. The bug is serious because it combines network-triggered timing behavior with stale callback state and expired stack memory. There is no verified evidence of exploitation in the wild and no verified public PoC from the available materials, but defenders should still prioritize patch validation.

The most responsible stance is simple: do not guess based on severity labels alone, and do not wait for KEV listing before acting. Verify whether your Zephyr build includes commit cd27da58eedb8d0fe380dd340b81ca5afa35de45, work with vendors to confirm patch status, and test DNS-heavy workflows for signs of instability until patched.

For more information on related vulnerabilities, check out our articles on what is JWT and passkeys standards.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.