CVE-2026-10773

The DHCPv4 client helper netdhcpv4msgtypename() in subsys/net/lib/dhcpv4/dhcpv4.c indexes a static 8-element const char * name table after a faulty bounds check. The guard used msgtype <= sizeof(name) instead of msgtype <= ARRAYSIZE(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[msgtype - 1] to read past the end of the array.

The msgtype value originates from the DHCP MESSAGE TYPE option, which is read as an unchecked raw byte from a received packet (netpktreadu8) 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 (NETDBG / LOGDBG), so the out-of-bounds read is triggerable only when the DHCPv4 log module is built at DEBUG level (CONFIGNETDHCPV4LOGLEVELDBG), 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 ARRAYSIZE, restoring the correct 1..8 acceptance window.