CVE-2026-10773

Zephyr RTOS's DHCPv4 client contains a bounds-check bug in its message-type lookup helper net_dhcpv4_msg_type_name(), where the guard compares the message type against the byte size of the name-pointer array (sizeof, 32 or 64 bytes) instead of its element count (8), letting message types 9 through 32/64 pass the check and index past the end of the table. Because the message type is taken unvalidated from the DHCP MESSAGE TYPE option of a received packet, any DHCP server — or any host able to inject spoofed DHCP replies onto the client's link — can trigger the out-of-bounds read, but only when the DHCPv4 module is compiled with debug-level logging (CONFIG_NET_DHCPV4_LOG_LEVEL_DBG), which is not the default configuration. An attacker most likely crashes the DHCP client through a wild-pointer dereference in a debug log statement (denial of service), and may potentially disclose the contents of an adjacent pointer via the log output. Affected users are Zephyr-based devices that enable both the DHCPv4 client and DHCPv4 debug logging — largely development and prototype builds rather than typical production firmware. No in-the-wild exploitation is reported (EPSS 0.3%, not in CISA KEV); a public Zephyr security advisory (GHSA-r5hq-xq42-wcfq) is available and the fix restores the correct 1..8 acceptance window by replacing sizeof with ARRAY_SIZE.

What to do: Audit firmware builds for CONFIG_NET_DHCPV4_LOG_LEVEL_DBG with the DHCPv4 client enabled; if present, upgrade Zephyr to a release incorporating the ARRAY_SIZE fix per GHSA-r5hq-xq42-wcfq. As an interim mitigation, rebuild without DHCPv4 debug logging or ensure only trusted hosts can send DHCP replies on the client's link. Deployments that do not use the DHCPv4 client or do not compile DHCPv4 logging at DEBUG level are not exposed.