CVE-2026-10666: Zephyr RTOS IPv4 Parsing DoS Vulnerability

CVE-2026-10666 Overview

CVE-2026-10666 is a stack buffer overflow [CWE-121] in the Zephyr RTOS network utility function parse_ipv4() located in subsys/net/ip/utils.c. The function copies the port portion of an a.b.c.d:port string into a fixed 17-byte stack buffer without consulting the destination size. An attacker who supplies a crafted address string with a long suffix after the colon triggers an out-of-bounds stack write with attacker-controlled length and contents. The defect was introduced in Zephyr v1.9.0 and shipped in every release through v4.4.0. Any application that resolves a network-influenced address string through zsock_getaddrinfo(), DNS server-string configuration, or the eswifi Wi-Fi co-processor DNS-response path is exposed.

Critical Impact
Remote, unauthenticated attackers can corrupt the stack of Zephyr-based devices via a crafted IPv4 address literal, causing denial of service and potentially achieving control-flow hijack on embedded systems.

Affected Products

Zephyr RTOS v1.9.0 through v4.4.0
Applications using zsock_getaddrinfo() with network-influenced input
Devices using the eswifi Wi-Fi co-processor DNS-response path

Discovery Timeline

2026-07-12 - CVE-2026-10666 published to NVD
2026-07-17 - Last updated in NVD database

Technical Details for CVE-2026-10666

Vulnerability Analysis

The defect resides in parse_ipv4() within subsys/net/ip/utils.c, reached via net_ipaddr_parse() when handling strings of the form a.b.c.d:port. The function declares a fixed 17-byte stack buffer, char ipaddr[NET_IPV4_ADDR_LEN + 1], and computes the port copy length as str_len - end - 1. Here str_len is the full unbounded input length while end is only the offset of the : delimiter, bounded to 15 bytes. Because the destination size is never consulted, a suffix of hundreds of bytes after the colon writes past the buffer.

The copy uses memcpy of the suffix plus a trailing NUL, so both the length and the content of the overflow are fully attacker-controlled. On architectures where Zephyr does not enable stack canaries or MPU-based stack protection, this enables saved return address overwrite. The equivalent IPv6 [addr]:port path in parse_ipv6() contains the same unbounded copy and is addressed in a separate commit.

Root Cause

The root cause is missing destination-size validation in the port-string extraction logic. The parser trusts an attacker-supplied length derived from the outer string boundary rather than the fixed-size destination buffer.

Attack Vector

Exploitation requires only that a Zephyr application pass an attacker-influenced string to a resolver API. Common entry points include DNS server configuration strings, zsock_getaddrinfo() calls on user input, and DNS responses processed by the eswifi driver. No authentication or user interaction is required.

// Patch: subsys/net/ip/utils.c - convert_port() now validates length
// before copying into a small dedicated buffer.
#if defined(CONFIG_NET_IP)
-static bool convert_port(const char *buf, uint16_t *port)
+static bool convert_port(const char *buf, size_t buf_len, uint16_t *port)
 {
+	char port_buf[sizeof("65535")];
 	unsigned long tmp;
 	char *endptr;
+	size_t len = buf_len;
+	size_t i;
+
+	for (i = 0U; i < buf_len; i++) {
+		if (buf[i] == '\0') {
+			len = i;
+			break;
+		}
+	}
+
+	if (len == 0U || len > (sizeof(port_buf) - 1U)) {
+		return false;
+	}
+
+	memcpy(port_buf, buf, len);
+	port_buf[len] = '\0';

-	tmp = strtoul(buf, &endptr, 10);
+	tmp = strtoul(port_buf, &endptr, 10);
// Source: https://github.com/zephyrproject-rtos/zephyr/commit/1c8d19a51f9a3c1be6de53854c8ad8c2720a0f48

Detection Methods for CVE-2026-10666

Indicators of Compromise

Zephyr device crashes or resets immediately after processing a DNS server configuration string or resolver call.
Network packets or configuration values containing IPv4 literals with abnormally long numeric suffixes after the : delimiter.
Unexpected stack traces referencing parse_ipv4(), net_ipaddr_parse(), or convert_port() in device fault logs.

Detection Strategies

Perform source-level auditing of firmware for calls to net_ipaddr_parse() and zsock_getaddrinfo() that accept externally influenced input.
Enable Zephyr CONFIG_STACK_CANARIES and CONFIG_HW_STACK_PROTECTION so overflow attempts trigger detectable fault handlers.
Fuzz DNS server configuration, socket resolver, and eswifi DNS-response code paths with oversized a.b.c.d:port inputs.

Monitoring Recommendations

Log and alert on kernel fault handlers triggered on networking threads in production fleets.
Inspect telemetry from network-facing embedded devices for repeated resets correlated with inbound DNS or configuration traffic.
Track Zephyr firmware version inventory to identify devices still running versions v1.9.0 through v4.4.0.

How to Mitigate CVE-2026-10666

Immediate Actions Required

Upgrade Zephyr firmware to a release containing commits 1c8d19a5 and 6e119a63 from the upstream zephyrproject-rtos/zephyr repository.
Restrict which components may pass externally sourced strings to net_ipaddr_parse() and the socket resolver APIs.
Sanitize DNS server strings and any configuration input that accepts host:port literals before passing them to the network stack.

Patch Information

The upstream fix is published under GitHub Security Advisory GHSA-532c-7g7f-jhmh. The IPv4 fix is delivered in commit 1c8d19a5 and the IPv6 fix in commit 6e119a63. Both patches replace the unbounded copy with a length-validated convert_port() helper that writes into a small dedicated 6-byte buffer sized for the maximum port string 65535.

Workarounds

Reject or truncate address strings longer than 21 characters (aaa.bbb.ccc.ddd:65535) at the application layer before calling resolver APIs.
Disable network features that resolve untrusted host:port strings until firmware can be updated.
Enable hardware stack protection (CONFIG_HW_STACK_PROTECTION) and MPU-based stack guards to convert exploitation attempts into recoverable faults.

bash

# Application-layer length validation before calling resolver APIs
# Reject any host:port literal longer than the maximum valid IPv4 form
MAX_IPV4_HOSTPORT_LEN=21   # aaa.bbb.ccc.ddd:65535
if [ ${#INPUT} -gt ${MAX_IPV4_HOSTPORT_LEN} ]; then
    echo "reject: address literal exceeds maximum length" >&2
    exit 1
fi