CVE-2026-10652 in zephyr
Summary
by MITRE • 06/30/2026
Zephyr's DNS resolver (subsys/net/lib/dns) parses resource records from DNS responses in dns_unpack_answer(), which validated only the fixed RR header (type, class, TTL, rdlength) and accepted any attacker-declared rdlength, including one extending past the end of the received datagram. The TXT and SRV consumers in dns_validate_record() (resolve.c) then read up to rdlength bytes (clamped only to a record-type maximum such as DNS_MAX_TEXT_SIZE, default 64, not to the packet) from the receive buffer via memcpy without their own bounds check, and pass the result to the application's resolve callback. A malicious or spoofed DNS server, an on-path attacker forging UDP DNS replies, or (with mDNS/LLMNR enabled) any LAN node can craft a truncated TXT or SRV response that causes an out-of-bounds read of adjacent receive-pool memory; the disclosed stale bytes (residual contents of prior DNS packets / uninitialized pool memory) are returned to the application as TXT/SRV record contents, an information leak, and may in some configurations cross the allocation boundary and fault, causing a denial of service. The read is bounded (~64 bytes for TXT, ~6 for SRV) and read-only (no write). The fix rejects any record whose declared rdata extends past dns_msg->msg_size at the single chokepoint in dns_unpack_answer(). Affected: v4.3.0 and v4.4.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/30/2026
The vulnerability resides within Zephyr's DNS resolver implementation in the subsys/net/lib/dns subsystem where the dns_unpack_answer() function processes DNS resource records without proper bounds validation. This function only validates the fixed portion of the resource record header including type, class, TTL, and rdlength fields but fails to verify that the declared rdata length does not exceed the actual packet boundaries. The flaw creates a critical security gap where an attacker can manipulate the rdlength field to point beyond the legitimate end of the received datagram, leading to out-of-bounds memory access patterns. This issue is particularly concerning as it operates at a fundamental level of DNS processing and affects how the system handles response validation.
The technical execution of this vulnerability occurs when dns_validate_record() processes TXT and SRV record types in resolve.c, where the system reads up to rdlength bytes from the receive buffer without additional bounds checking. The memcpy operation pulls data based on the attacker-controlled rdlength value, which is clamped only against record-type specific maximums like DNS_MAX_TEXT_SIZE (64 bytes) rather than the actual packet size limits. This creates a scenario where stale memory contents from previous DNS packets or uninitialized pool memory are read and returned to applications through the resolve callback mechanism. The vulnerability manifests as an information disclosure where residual data from prior network operations becomes accessible to legitimate applications.
The operational impact of this vulnerability extends beyond simple information leakage to include potential denial of service conditions in certain configurations. When the maliciously crafted rdlength value causes memory access across allocation boundaries, system faults may occur leading to application crashes or system instability. The read operations are limited to approximately 64 bytes for TXT records and roughly 6 bytes for SRV records, making them relatively constrained but still significant given their potential to expose sensitive data from network buffers. This vulnerability affects specific Zephyr versions including v4.3.0 and v4.4.0, representing a targeted issue within the network stack's DNS processing capabilities.
The mitigation strategy implemented in the fix addresses the root cause by establishing a single chokepoint in dns_unpack_answer() that rejects any record where the declared rdata extends beyond the dns_msg->msg_size boundary. This approach aligns with security best practices for memory safety and follows principles similar to those outlined in CWE-129 Input Validation and CWE-787 Out-of-bounds Write. The solution demonstrates proper bounds checking methodology that prevents attackers from exploiting the discrepancy between attacker-controlled length fields and actual packet boundaries, effectively closing the information disclosure and potential DoS attack vectors. This fix represents a defensive programming approach that ensures all DNS responses are validated against their physical packet limits before any data processing occurs, thereby protecting against both the immediate security implications and broader system stability concerns. The remediation approach also aligns with ATT&CK technique T1071.004 Application Layer Protocol: DNS where adversaries manipulate DNS responses to extract information or cause system instability through malformed packet structures.