Zephyr PTP: unvalidated Delay_Resp message interval lets an on-link peer wedge the PTP thread and flood the network
Summary
| CVE | CVE-2026-87042 |
|---|---|
| State | PUBLISHED |
| Assigner | zephyr |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-11-10 22:21:12 UTC |
| Updated | 2026-11-10 22:21:12 UTC |
| 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. |
Risk And Classification
Primary CVSS: v3.1 6.5 MEDIUM from [email protected]
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Problem Types: CWE-400 | CWE-400 dos
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 6.5 | MEDIUM | CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| 3.1 | CNA | CVSS | 6.5 | MEDIUM | CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
CVSS v3.1 Breakdown
Attack Vector
AdjacentAttack Complexity
LowPrivileges Required
NoneUser Interaction
NoneScope
UnchangedConfidentiality
NoneIntegrity
NoneAvailability
HighCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Zephyrproject | Zephyr | affected 3.7.0 4.3.2 semver | Not specified |
| CNA | Zephyrproject | Zephyr | affected 4.4.0 4.5.0 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/zephyrproject-rtos/zephyr/commit/f6b9459f082ac8cc18b7d20a5c4c... | [email protected] | github.com | |
| github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-cx9q-8hq3-... | [email protected] | github.com | |
| github.com/zephyrproject-rtos/zephyr/commit/334bf57f416f2f65745e68db98ed... | [email protected] | github.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.