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.

Project Subscriptions

No data.

Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Sat, 01 Aug 2026 13:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Sat, 01 Aug 2026 12:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Out-of-bounds read in DHCPv4 client message-type name lookup (net_dhcpv4_msg_type_name)
Weaknesses CWE-125
CWE-682
References
Metrics cvssV3_1

{'score': 5.4, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L'}


Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-08-01T12:21:17.622Z

Reserved: 2026-06-03T15:44:06.548Z

Link: CVE-2026-10773

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-01T13:30:03Z

Weaknesses