CVE-2026-87042: zephyr Denial of Service (CVSS 6.5)

Description

The IEEE 1588 (PTP) port implementation in subsys/net/lib/ptp/port.c adopted the logMessageInterval field of a received Delay_Resp message without any validation. port_delay_resp_msg_process() stored the raw wire value (a full-range int8_t) into port_ds.log_min_delay_req_interval, and that value is later used as a shift count by port_timer_set_timeout() when the Delay_Req 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 uint64_t; 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 Delay_Resp 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 Delay_Req. Any node on the same link can therefore inject a single crafted Delay_Resp, 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 Delay_Req on every tick. Each transmission takes a buffer from the fixed CONFIG_PTP_MSG_POLL_SIZE message slab (default 10) and holds it on port->delay_req_list for three seconds, so the slab is emptied within milliseconds and ptp_msg_alloc() then blocks with K_FOREVER 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 Delay_Req 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 port_sync_msg_process(), 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.

Metrics

CVSS 3.1

6.5/10

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Weakness Enumeration

CWE-400

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
zephyrproject	zephyr	>= 3.7.0, < 4.3.2; >= 4.4.0, < 4.5.0

References

Timeline

Published: Nov 10, 2026
Last Modified: Nov 10, 2026
Status: Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-87042?

The IEEE 1588 (PTP) port implementation in subsys/net/lib/ptp/port.c adopted the logMessageInterval field of a received Delay_Resp message without any validation. port_delay_resp_msg_process() stored the raw wire value (a full-range int8_t) into port_ds.log_min_delay_req_interval, and that value is later used as a shift count by port_timer_set_timeout() when the Delay_Req 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 uint64_t; 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 Delay_Resp 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 Delay_Req. Any node on the same link can therefore inject a single crafted Delay_Resp, 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 Delay_Req on every tick. Each transmission takes a buffer from the fixed CONFIG_PTP_MSG_POLL_SIZE message slab (default 10) and holds it on port->delay_req_list for three seconds, so the slab is emptied within milliseconds and ptp_msg_alloc() then blocks with K_FOREVER 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 Delay_Req 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 port_sync_msg_process(), 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.

How severe is CVE-2026-87042?

CVE-2026-87042 has a CVSS score of 6.5/10 (MEDIUM severity).

How do I fix CVE-2026-87042?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →