CVE-2026-10773 in Zephyr
Summary
by MITRE • 08/01/2026
The DHCPv4 client helper net_dhcpv4_msg_type_name() in subsys/net/lib/dhcpv4/dhcpv4.c indexes a static 8-element const char * name table after a faulty bounds check. The guard used msg_type <= sizeof(name) instead of msg_type <= ARRAY_SIZE(name); sizeof returns the byte size of the pointer array (32 on 32-bit, 64 on 64-bit targets) rather than the element count of 8, so message-type values from 9 up to that byte size pass the check and cause name[msg_type - 1] to read past the end of the array.
The msg_type value originates from the DHCP MESSAGE TYPE option, which is read as an unchecked raw byte from a received packet (net_pkt_read_u8) and passed unmodified into the lookup. A DHCP server, or any host able to inject a spoofed DHCP reply onto the client's link, can therefore drive the index out of bounds. The out-of-range slot yields a garbage const char * that is then dereferenced by a %s log conversion.
The lookup is reached only from a debug log statement (NET_DBG / LOG_DBG), so the out-of-bounds read is triggerable only when the DHCPv4 log module is built at DEBUG level (CONFIG_NET_DHCPV4_LOG_LEVEL_DBG), which is not the default configuration. When that condition holds, the result is an out-of-bounds read and a wild-pointer dereference: most likely a crash of the DHCP client (denial of service) and potentially disclosure of an adjacent pointer's contents through the log output. The fix replaces sizeof with ARRAY_SIZE, restoring the correct 1..8 acceptance window.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/01/2026
This vulnerability resides in the Zephyr RTOS DHCPv4 client implementation within the subsys/net/lib/dhcpv4/dhcpv4.c file where a classic buffer overflow occurs due to improper bounds checking during message type name lookup. The flaw manifests in the net_dhcpv4_msg_type_name() function which attempts to map DHCP message type values to their corresponding string representations using a static array of eight const char pointers. The vulnerability stems from a fundamental misunderstanding of how sizeof operator behaves with arrays, specifically when dealing with pointer arrays versus actual array sizes. When developers use sizeof(name) on an array that has been passed to a function, they receive the size of the pointer rather than the number of elements in the original array, creating a dangerous discrepancy between expected and actual bounds.
The technical execution path begins with DHCP packets received over the network where the message type is extracted using net_pkt_read_u8() without any validation or sanitization. This raw byte value, representing the DHCP message type, flows directly into the vulnerable lookup function without proper range checking. The flawed condition msg_type <= sizeof(name) allows values from 9 through the pointer size (32 on 32-bit systems, 64 on 64-bit systems) to pass validation when only values 1-8 should be permitted. This misconfiguration creates a direct out-of-bounds memory access pattern that can be exploited by any attacker capable of crafting and injecting spoofed DHCP replies onto the network segment.
The operational impact of this vulnerability aligns with CWE-129 and CWE-787 categories, representing an insufficient bounds check that leads to memory safety issues. The vulnerability specifically maps to ATT&CK technique T1059.007 for command and scripting interpreter execution through debug logging mechanisms. While the out-of-bounds read only occurs when DEBUG level logging is enabled via CONFIG_NET_DHCPV4_LOG_LEVEL_DBG, this condition can be triggered in development environments or when administrators explicitly enable verbose logging for troubleshooting purposes. The actual exploitation results in a wild pointer dereference that typically manifests as a denial of service condition causing the DHCP client process to crash, though there exists potential for information disclosure if adjacent memory contents are inadvertently exposed through log output formatting operations.
The mitigation strategy involves implementing proper array size checking using ARRAY_SIZE() macro instead of sizeof(), which correctly calculates the element count rather than pointer size. This change restores the intended bounds validation that restricts message type values to the legitimate range of 1-8, corresponding to the actual elements in the static lookup table. Additionally, security best practices suggest implementing input validation for all network-received data, including DHCP options, and avoiding reliance on debug logging configurations for security-sensitive operations. The fix should also consider adding more robust error handling for malformed DHCP packets and implementing proper bounds checking mechanisms that prevent similar issues in other parts of the network stack where array indexing occurs.