CVE-2026-10657: Zephyr mDNS Buffer Over-Read Denial of Service

Technical summary

CVE-2026-10657 is a classic out-of-bounds read in Zephyr's mDNS detection logic (subsys/net/lib/dns/resolve.c, dns_resolve_name_internal function). The vulnerability stems from memcmp(strrchr(query, '.'), ".local", 7), which unconditionally compares 7 bytes from the final dot's position, ignoring the actual remaining string length. When the hostname's final label is less than 7 characters—typical for .org, .com, .net, .io, and single-character TLDs—the read extends 1–2 bytes beyond the NUL terminator. The hostname originates from caller-supplied input via getaddrinfo()/dns_get_addr_info()/dns_resolve_name(), making it reachable from configuration sources or remote inputs. On memory-constrained allocations (e.g., exact strlen+1 byte buffers in userspace with k_usermode_string_alloc_copy), the over-read crosses allocation boundaries. If the boundary is unmapped—typical under MPU/memory-domain isolation or address sanitizers—a fault occurs. The over-read bytes are never dereferenced for use, so no information disclosure occurs. Presence requires CONFIG_MDNS_RESOLVER enabled. The fix replaces memcmp with strcmp to ensure NUL-safe comparison.

Business impact

This vulnerability poses a moderate operational risk to Zephyr-based IoT and embedded systems relying on mDNS. An operator or attacker capable of injecting hostnames—via configuration files, DNS server redirects, or application-level input—can trigger a denial of service. The impact is magnified in headless IoT deployments where crash recovery is manual or time-consuming. Organizations running Zephyr with mDNS enabled should assess whether hostname inputs are accessible to untrusted sources (e.g., downloaded configs, API responses, or network-supplied parameters). For edge systems with redundancy, impact is contained; for single-point-of-failure devices (sensors, gateways, firmware update servers), unexpected crashes disrupt operations. The low CVSS score reflects the limited attack surface and lack of confidentiality or integrity compromise, but operational availability is the primary concern.

Affected systems

Zephyr versions v1.10.0 and later with CONFIG_MDNS_RESOLVER enabled are affected. The vulnerability manifests only when mDNS resolution is compiled in. Affected systems include: embedded IoT devices (sensors, gateways, edge controllers), network-attached appliances, industrial IoT systems, and any Zephyr-based application that resolves .local or other short-suffix hostnames. Systems running Zephyr without mDNS resolver enabled, or versions prior to v1.10.0, are not affected. Devices with strict memory isolation (ARMv7-M with MPU, ARMv8-M, or systems running address sanitizers) are more likely to exhibit the crash; devices with permissive memory layouts may experience silent over-reads with no immediate symptom.

Exploitability

Exploitation requires the ability to inject or influence hostname input through configuration, command-line arguments, parsed URLs, or application-facing APIs. Direct network exploitation is indirect—an attacker must control a hostname that reaches the resolver (e.g., via malicious config file, compromised configuration server, or application-level input validation bypass). The attack is reliable on memory-protected systems (faults are deterministic), but less reliable on systems with flat memory or no guard pages (the over-read may not trigger a visible crash). No authentication is required, and user interaction is not needed if hostname input is automated (e.g., periodic config sync, DNS rebinding, or embedded configuration parsing). Complexity is low once input control is achieved. Overall exploitability is moderate: low complexity, high barrier to input control, but reliable impact once achieved.

Remediation

The vendor (Zephyr Project) has released a fix by replacing the fixed-length memcmp with a NUL-safe strcmp. Operators should update to a patched Zephyr version as provided in the vendor advisory. If immediate patching is not feasible, mitigate by: (1) disabling CONFIG_MDNS_RESOLVER at compile time if mDNS is not required, (2) restricting sources of hostname input (e.g., signed configuration files, allowlists), or (3) deploying memory-protection mechanisms (MPU, guard pages) if not already enabled. For systems already using memory protection or address sanitizers, crashes will alert operators to attempted exploitation; configure monitoring to detect and respond to these faults.

Patch guidance

Apply the vendor's patch or upgrade to a fixed Zephyr release version. Verify against the Zephyr Project advisory for the specific patched version number. The fix involves replacing memcmp(strrchr(query, '.'), ".local", 7) with strcmp(ptr, ".local") or equivalent NUL-safe string comparison. Patch testing should confirm that mDNS resolution continues to function correctly for .local hostnames and that no regression occurs in DNS resolution for standard TLDs (.com, .org, .net, .io, etc.). On systems with memory constraints, re-validate memory allocation sizes and guard-page configurations after patching.

Detection guidance

Monitor for repeated crashes or watchdog resets in Zephyr applications with mDNS enabled, especially if they correlate with hostname resolution attempts. Enable address sanitizer (if feasible in test/staging) to detect and log out-of-bounds reads. In production, log all hostname resolution requests (especially those with short suffixes like .com, .org, .io) and correlate with system faults. Audit configuration sources for unexpected or suspicious hostnames injected via config files, environment variables, or remote APIs. Systems with MPU/memory-domain isolation will naturally generate fault logs (e.g., ARM M-class HardFault) when the over-read crosses a protected boundary; correlate these with mDNS resolver activity. No in-memory signatures of exploitation are left; detection relies on behavioral anomalies (crashes) or logging input sources.

Why prioritize this

Prioritize patching based on exposure and operational criticality. HIGH priority if: (1) Zephyr devices are exposed to untrusted hostname input (config downloads, API-driven setup, public DNS rebinding), (2) the device is single-point-of-failure, or (3) mDNS is actively used in your deployment. MEDIUM priority if: (1) Zephyr devices are in closed networks with limited input sources, or (2) redundancy masks crashes. LOW priority if: (1) CONFIG_MDNS_RESOLVER is disabled, or (2) Zephyr is not deployed in critical paths. Given the low CVSS (3.7) and lack of KEV status, this is not a zero-day or immediate emergency, but should still be addressed in the next planned patch cycle for affected systems.

Risk score, explained

CVSS 3.7 (LOW) reflects: Attack Vector = Network (input can come from remote config sources, but requires intermediate compromise of configuration channels), Attack Complexity = High (memory protection or specific buffer layout required to trigger crash), Privileges Required = None, User Interaction = None, Scope = Unchanged, Confidentiality = None (no data exposure), Integrity = None (no data corruption), Availability = Low (denial of service via crash, but not widespread—only affects mDNS-enabled instances and specific input patterns). The score does not account for operational context; in a critical embedded system with no redundancy, risk is higher. Organizations should supplement CVSS with operational criticality assessment.

Frequently asked questions