Answer in brief
CVE-2026-10773 records a Medium severity (CVSS 5.4) vulnerability in Out-of-bounds read in DHCPv4 client message-type name lookup (net_dhcpv4_msg_type_name). The current sources do not mark it as known exploited. The current feed maps zephyrproject/zephyr (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps zephyrproject/zephyr (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| zephyrproject/zephyrgeneric | >=1.7.0 <4.5.0 | 4.5.0 |
Published upstream
Aug 1, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 3, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 3, 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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-10773 records a Medium severity (CVSS 5.4) vulnerability in Out-of-bounds read in DHCPv4 client message-type name lookup (net_dhcpv4_msg_type_name). The current sources do not mark it as known exploited. The current feed maps zephyrproject/zephyr (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps zephyrproject/zephyr (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| zephyrproject/zephyrgeneric | >=1.7.0 <4.5.0 | 4.5.0 |
Published upstream
Aug 1, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 3, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 3, 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.
Quoted source text, attributed separately from HOL analysis.