CVE-2026-87042

What it is

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.

At a glance

Exploitability

Can be exploited from the same network segment without logging in. High risk of service disruption.

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2026-09-08 18:40 UTC ReservedThe CVE id was reserved by its CNA
2. 2026-11-10 22:21 UTC PublishedDisclosed publicly on CVE.org and NVD
3. 2026-11-10 22:21 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: not scored yet.
• Severity: 6.5 MEDIUM (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2026-11-10 22:21 UTC

Last modified

2026-11-10 22:21 UTC

Weakness

CWE-400 · Uncontrolled resource consumption

Record status

Awaiting Analysis

Attack profile CVSS 3.1 · 6.5

Attack vector

Adjacent network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-87042.md and follow it. Check whether this project is affected by CVE-2026-87042. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge