CVE-2026-87042: Zephyr PTP: unvalidated Delay_Resp message interval lets an on-link peer wedge the PTP thread and flood the network
The IEEE 1588 (PTP) port implementation in subsys/net/lib/ptp/port.c adopted the logMessageInterval field of a received DelayResp message without any validation. portdelayrespmsgprocess() stored the raw wire value (a full-range int8t) into portds.logmindelayreqinterval, and that value is later used as a shift count by porttimersettimeout() when the DelayReq timer is armed. Values below about -30 truncate the computed timeout to zero, and values with a magnitude of 64 or more perform an undefined shift of a uint64t; the standards-defined "not applicable" encoding 0x7F fell into the latter case as well.
PTP messages are received over unauthenticated link-local traffic (UDP multicast on 224.0.1.129, IPv6 multicast, or raw IEEE 802.3), and the handler accepts a DelayResp from any sender as long as the port is a time receiver using the end-to-end delay mechanism and the message echoes the port identity and a pending sequence id — both of which the victim itself broadcasts in its DelayReq. Any node on the same link can therefore inject a single crafted DelayResp, or simply become the time transmitter and advertise the bogus interval.
Once the delay timer is armed with a zero timeout, the cooperative PTP thread re-arms and retransmits a DelayReq on every tick. Each transmission takes a buffer from the fixed CONFIGPTPMSGPOLLSIZE message slab (default 10) and holds it on port->delayreqlist for three seconds, so the slab is emptied within milliseconds and ptpmsgalloc() then blocks with KFOREVER inside the only thread that frees those buffers — permanently stalling time synchronization until reboot. Where a transmit-timestamp callback on another thread keeps recycling buffers, the result is instead a sustained multicast DelayReq flood and continuous CPU consumption. There is no memory corruption and no disclosure of data; the impact is availability of the PTP subsystem and of the local network segment.
The fix rejects intervals outside a representable range and treats 0x7F as "not applicable" as required by IEEE 1588-2019 Table 42. The equivalent unchecked adoption of logMessageInterval from Sync messages in portsyncmsgprocess(), a weaker variant of the same issue, is fixed by the companion change 334bf57f416f (#118150), which applies the same range check, ignores the field for unicast Sync messages and treats 0x7F as not applicable.