{"api_version":"1","generated_at":"2026-11-10T23:06:08+00:00","cve":"CVE-2026-87042","urls":{"html":"https://cve.report/CVE-2026-87042","api":"https://cve.report/api/cve/CVE-2026-87042.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-87042","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-87042"},"summary":{"title":"Zephyr PTP: unvalidated Delay_Resp message interval lets an on-link peer wedge the PTP thread and flood the network","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.\n\nPTP 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.\n\nOnce 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.\n\nThe 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.","state":"PUBLISHED","assigner":"zephyr","published_at":"2026-11-10 22:21:12","updated_at":"2026-11-10 22:21:12"},"problem_types":["CWE-400","CWE-400 dos"],"metrics":[{"version":"3.1","source":"vulnerabilities@zephyrproject.org","type":"Secondary","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"baseScore":6.5,"baseSeverity":"MEDIUM","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"}}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/f6b9459f082ac8cc18b7d20a5c4ce1d86b7a55b5","name":"https://github.com/zephyrproject-rtos/zephyr/commit/f6b9459f082ac8cc18b7d20a5c4ce1d86b7a55b5","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-cx9q-8hq3-7hpr","name":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-cx9q-8hq3-7hpr","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/334bf57f416f2f65745e68db98edf3615ec4e7ab","name":"https://github.com/zephyrproject-rtos/zephyr/commit/334bf57f416f2f65745e68db98edf3615ec4e7ab","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-87042","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-87042","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"zephyrproject","product":"zephyr","version":"affected 3.7.0 4.3.2 semver","platforms":[]},{"source":"CNA","vendor":"zephyrproject","product":"zephyr","version":"affected 4.4.0 4.5.0 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"collectionURL":"https://github.com/zephyrproject-rtos/zephyr","defaultStatus":"unaffected","packageName":"zephyr","product":"zephyr","programFiles":["subsys/net/lib/ptp/port.c"],"programRoutines":[{"name":"port_delay_resp_msg_process"},{"name":"port_sync_msg_process"},{"name":"port_timer_set_timeout"}],"vendor":"zephyrproject","versions":[{"lessThan":"4.3.2","status":"affected","version":"3.7.0","versionType":"semver"},{"lessThan":"4.5.0","status":"affected","version":"4.4.0","versionType":"semver"}]}],"descriptions":[{"lang":"en","value":"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.\n\nPTP 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.\n\nOnce 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.\n\nThe 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":[{"cvssV3_1":{"baseScore":6.5,"baseSeverity":"MEDIUM","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"format":"CVSS"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-400","description":"dos","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-11-10T22:07:40.237Z","orgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","shortName":"zephyr"},"references":[{"name":"Fix commit f6b9459f082a","tags":["patch"],"url":"https://github.com/zephyrproject-rtos/zephyr/commit/f6b9459f082ac8cc18b7d20a5c4ce1d86b7a55b5"},{"name":"Fix commit 334bf57f416f","tags":["patch"],"url":"https://github.com/zephyrproject-rtos/zephyr/commit/334bf57f416f2f65745e68db98edf3615ec4e7ab"},{"name":"GHSA-cx9q-8hq3-7hpr","url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-cx9q-8hq3-7hpr"}],"title":"Zephyr PTP: unvalidated Delay_Resp message interval lets an on-link peer wedge the PTP thread and flood the network","x_generator":{"engine":"cvelib 1.8.0"}}},"cveMetadata":{"assignerOrgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","assignerShortName":"zephyr","cveId":"CVE-2026-87042","datePublished":"2026-11-10T22:07:40.237Z","dateReserved":"2026-09-08T18:40:46.092Z","dateUpdated":"2026-11-10T22:07:40.237Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-10 22:21:12","lastModifiedDate":"2026-11-10 22:21:12","problem_types":["CWE-400","CWE-400 dos"],"metrics":{"cvssMetricV31":[{"source":"vulnerabilities@zephyrproject.org","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":2.8,"impactScore":3.6}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"87042","Ordinal":"1","Title":"Zephyr PTP: unvalidated Delay_Resp message interval lets an on-l","CVE":"CVE-2026-87042","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"87042","Ordinal":"1","NoteData":"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.\n\nPTP 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.\n\nOnce 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.\n\nThe 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.","Type":"Description","Title":"Zephyr PTP: unvalidated Delay_Resp message interval lets an on-l"}]}}}