---
id: "CVE-2026-87042"
page: "https://infrastack.ai/live/CVE-2026-87042"
kind: "vulnerability"
aliases: ["CVE-2026-87042"]
title: "Zephyr: unchecked PTP Delay_Resp interval lets a LAN peer stall time sync"
severity: "medium"
cvss: 6.5
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded", "iot", "ptp", "runtime", "zephyr"]
not_affected_if: ["no-link-local-attacker", "peer-to-peer-delay", "ptp-disabled"]
published_at: "2026-11-10T22:21:12+00:00"
first_seen_at: "2026-11-10T22:27:30+00:00"
updated_at: "2026-11-10T22:29:16+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87042", "first_seen_at": "2026-11-10T22:27:30+00:00"}]
exploit_sources: []
---

# Zephyr: unchecked PTP Delay_Resp interval lets a LAN peer stall time sync

Link for people: https://infrastack.ai/live/CVE-2026-87042 (this .md is for agents)

Zephyr's PTP port code copies an unvalidated logMessageInterval from a received Delay_Resp and uses it as a shift count, so a crafted packet can make the timer fire at zero and flood or exhaust PTP message buffers. An attacker on the same link can stall time synchronization until reboot, with no data disclosure.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the device runs Zephyr with PTP enabled (`CONFIG_PTP` set in the build configuration)
- Check whether the port is a time receiver using the end-to-end delay mechanism
- Check the Zephyr version against the product ranges in the NVD entry (fixed version not stated in the sources given)

## Timeline

- 2026-11-10T22:27:30+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-87042

## Documents

- [advisory] Vendor advisory: github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-cx9q-8hq3-7hpr
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/334bf57f416f2f65745e68db98edf3615ec4e7ab
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/f6b9459f082ac8cc18b7d20a5c4ce1d86b7a55b5

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_