CVE-2026-13481
PoC nicheOut-of-bounds read in Zephyr RTOS IEEE 1588 PTP management parser
CVE-2026-13481 is an out-of-bounds read (CWE-125) in the IEEE 1588 PTP management-message parser of the Zephyr RTOS networking stack (subsys/net/lib/ptp/tlv.c), where the PTP_MGMT_TIME management id is cast to a 10-byte struct ptp_timestamp and read without first checking that the TLV data field is at least that long — the only management id in the switch missing this validation. An adjacent attacker on the local PTP segment can send a management message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and then byte-swap and write back 8 bytes beyond the validated data; the path is reachable whenever CONFIG_PTP is enabled. The attacker gains minor information exposure of adjacent bytes within the same message object and can corrupt the device's parsed management TIME value; there is no crash, no past-allocation memory corruption, and no reachable reference-count corruption. Only Zephyr builds with the PTP subsystem enabled are affected — a profile typical of industrial and telecom precision-timing deployments — and the Zephyr Project (the CNA) has published advisory GHSA-mh5r-jxh8-hxwx alongside the fix. Exploitation status: one public advisory/PoC reference exists, but there is no evidence of in-the-wild exploitation (EPSS 0.2%, not in CISA KEV).
What to do: Upgrade to a Zephyr release that includes the upstream fix, which adds the missing guard — returning -EBADMSG when the TLV data is shorter than sizeof(struct ptp_timestamp) — in tlv_mgmt_post_recv(), and consult GHSA-mh5r-jxh8-hxwx for the exact fixed version for your branch. If patching is not immediately possible, disable CONFIG_PTP or restrict acceptance of PTP management messages to trusted adjacent peers. Given the low EPSS and absence of known in-the-wild exploitation this is not urgent, but exposed precision-timing deployments should prioritize the update.
| zephyrproject zephyr | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
The IEEE 1588 PTP management-message parser in subsys/net/lib/ptp/tlv.c mishandles the PTP_MGMT_TIME management id. In tlv_mgmt_post_recv(), the PTP_MGMT_TIME case casts mgmt_tlv->data to a 10-byte struct ptp_timestamp and reads it (then byte-swaps and writes it back) without first checking that the TLV data field is at least sizeof(struct ptp_timestamp). Every sibling management id in the same switch validates its length first; PTP_MGMT_TIME was the only case lacking that check. The length passed in is the management data size (tlv->length - 2), and the upstream guard in ptp_tlv_post_recv() only requires tlv->length > 2, while msg_tlv_post_recv() validates only that the TLV fits within the received byte count, not a per-id minimum. A peer on the local PTP segment can therefore send a PTP_MSG_MANAGEMENT message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and write 8 bytes beyond the validated data. The message type and TLV contents are taken straight off the wire, so the path is reachable by any adjacent attacker when CONFIG_PTP is enabled. The over-read and write-back stay within the struct ptp_msg allocation (mgmt_tlv->data lives in the leading mtu[NET_ETH_MTU] union member, so data + 10 lands at most a few bytes past mtu[], inside the same object), so this is an out-of-bounds read of adjacent in-object memory plus a bounded in-place corruption of the message's parsed timestamp, not past-allocation memory corruption. Impact is limited to minor information exposure of adjacent bytes and corruption of the device's parsed management TIME value; there is no crash on the access and no reachable reference-count corruption. The fix adds if (length < sizeof(struct ptp_timestamp)) { return -EBADMSG; } before the cast, matching the other management-id cases and fully closing the receive-path defect.
- Vendors
- zephyrproject
- Products
- zephyr
- Weakness
- CWE-125
- Vector
- CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
In the news0 stories
No ingested article mentions this CVE yet.