CVE-2026-13481 in Zephyr
Summary
by MITRE • 08/26/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in the IEEE 1588 Precision Time Protocol implementation within the subsys/net/lib/ptp/tlv.c module represents a critical input validation failure that allows for out-of-bounds memory access. Specifically, the parser handling the PTP_MGMT_TIME management identifier fails to verify the length of the Type-Length-Value data field before attempting to cast it into a fixed-size structure known as struct ptp_timestamp. This structural timestamp requires exactly ten bytes of data to be processed correctly, yet the code proceeds with casting and processing the buffer without confirming that this minimum threshold is met. In contrast, every other management identifier within the same switch statement performs an explicit length check prior to accessing the payload, highlighting a distinct inconsistency in defensive coding practices for this specific protocol message type.
The root cause lies in the interaction between multiple layers of validation logic. The upstream function ptp_tlv_post_recv() enforces only that the total TLV length exceeds two bytes, which is insufficient given the variable size requirements of different management IDs. Similarly, msg_tlv_post_recv() validates that the TLV fits within the received byte count but does not enforce per-identifier minimum sizes. Consequently, an attacker positioned on the local PTP segment can craft a malicious PTP_MSG_MANAGEMENT message containing a truncated PTP_MGMT_TIME TLV with data as small as two bytes. When this malformed packet is processed by the vulnerable function tlv_mgmt_post_recv(), the system attempts to read and byte-swap ten bytes from a buffer that may contain significantly less valid data, leading to an out-of-bounds read operation.
The operational impact of this vulnerability involves both information exposure and state corruption, though it does not result in arbitrary code execution or denial of service through crashes. The memory access remains confined within the bounds of the struct ptp_msg allocation because the mgmt_tlv->data pointer resides within a leading mtu[NET_ETH_MTU] union member. This means that reading ten bytes from a short buffer results in accessing adjacent in-object memory rather than crossing into unrelated heap or stack regions. The immediate consequence is the leakage of sensitive data contained in those adjacent memory locations, which could potentially reveal internal state information about the device. Furthermore, the subsequent write-back operation corrupts the parsed timestamp value within the message structure itself, potentially disrupting time synchronization accuracy for devices relying on this PTP implementation.
From a threat modeling perspective, this flaw aligns with CWE-125, Out-of-bounds Read, as it involves accessing memory beyond the intended buffer boundary due to insufficient validation of input length. It also relates to CWE-20, Improper Input Validation, specifically regarding the failure to enforce minimum size constraints for structured data fields. In terms of attack vectors, this vulnerability is exploitable by any adjacent attacker on the same network segment who can inject crafted PTP messages, corresponding to techniques found in MITRE ATT&CK such as Network Sniffing or Protocol Manipulation depending on the specific exploitation goal. The reachability condition requires that CONFIG_PTP be enabled, limiting the attack surface to devices actively participating in precision time synchronization networks.
To mitigate this vulnerability and prevent similar issues in future development, it is imperative to implement strict length validation for all Type-Length-Value fields before any type casting or memory access occurs. The recommended fix involves adding a conditional check that verifies whether the available data length is greater than or equal to sizeof(struct ptp_timestamp) prior to processing. If the condition fails, the parser should return an error code such as -EBADMSG to reject the malformed message immediately. This approach ensures parity with other management ID handlers and closes the receive-path defect entirely. Security teams should audit similar protocol parsers for consistent application of input validation rules across all identifier cases to maintain robustness against crafted network traffic.