CVE-2026-79980: crypto in zephyrproject zephyr

The DHCPv4 client in Zephyr maintained its transaction identifier (xid) as a counter seeded once at startup and incremented predictably, rather than generating a new random xid per transaction as RFC 2131 requires. This predictable xid is the only unpredictable token validating DHCP replies. Because the UDP socket accepts replies from any source without server-identifier or source address checks, an attacker who learns one xid can forge valid DHCP replies throughout the device's uptime. Forged replies can alter the device's default gateway and DNS settings or disrupt lease renewal and configuration. The fix generates a fresh random xid at each transaction start (SELECTING, RENEWING, REBINDING, INIT/INIT-REBOOT), while REQUESTING and DECLINE keep their xid as required. This also improves handling of slow servers and randomness in initial discover backoff.

An attacker on the same network segment or with access to a previously joined network can predict DHCP transaction identifiers and forge DHCP replies accepted by the client. This can redirect the device's network traffic to attacker-controlled gateways and DNS servers, potentially enabling traffic interception or manipulation. Additionally, forged DHCPACK or DHCPNAK messages can disrupt the device's IP configuration and connectivity. The vulnerability affects confidentiality, integrity, and availability of network communications.

A patch is available that addresses this vulnerability by generating a fresh random transaction identifier for each DHCP transaction phase as required by RFC 2131. Users should apply the official fix from the Zephyr project to remediate this issue. Since this is a client-side vulnerability in an embedded network stack, no other mitigations are specified by the vendor advisory.