CVE-2026-12632 in Zephyr
Summary
by MITRE • 08/19/2026
Zephyr's Precision Time Protocol receive handler ptp_msg_post_recv() in subsys/net/lib/ptp/msg.c takes the 4-bit message type straight off the wire via ptp_msg_type() (msg->header.type_major_sdo_id & 0xF, range 0-15) and uses it to index the msg_size[] table. That table only defines entries up to PTP_MSG_MANAGEMENT (0xD), giving it ARRAY_SIZE == 14. Before the fix there was no upper-bound check, so the undefined types 0xE and 0xF indexed one or two int slots past the end of the array — an out-of-bounds read of adjacent read-only data.
The out-of-bounds value is then reused as a length: it gates msg_size[type] > cnt, and when it is small or negative it makes cnt - msg_size[type] a large positive budget passed to msg_tlv_post_recv(), whose TLV loop then walks the message suffix past the received bytes, performing further out-of-bounds reads and in-place byte-swap writes on memory beyond the message slab.
The defect is reached directly from the network: ptp_port_event_gen() in subsys/net/lib/ptp/port.c reads a PTP frame with ptp_transport_recv() and calls ptp_msg_post_recv() with the attacker-chosen type. PTP uses UDP multicast or raw Ethernet (0x88F7) and is unauthenticated, so any host on the same link can trigger the indexing on a CONFIG_PTP-enabled node with no preconditions.
The reliably reproducible impact is a denial of service (fault/crash); a limited memory-corruption path exists but depends on the build-specific value adjacent to msg_size[], which the attacker cannot tune. The fix rejects type >= ARRAY_SIZE(msg_size) with -EBADMSG before any indexing.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability resides within the Precision Time Protocol implementation in the Zephyr real-time operating system, specifically affecting the message post-receive handler function ptp_msg_post_recv located in subsys/net/lib/ptp/msg.c. This component is responsible for processing incoming PTP messages and validating their structure before further handling. The core technical flaw stems from an improper validation of the message type field extracted directly from network traffic. When a PTP frame arrives, the system extracts the four-bit message type identifier using bitwise operations on the header data. This value ranges from zero to fifteen but is used as a direct index into a static array named msg_size without any prior bounds checking. The msg_size table contains predefined sizes for valid protocol messages and has an explicit size of fourteen elements, covering types through PTP_MSG_MANAGEMENT which corresponds to hexadecimal D or decimal thirteen. Consequently, message types with values E (fourteen) and F (fifteen), while technically defined in the IEEE 1588 standard as reserved or implementation-specific fields, fall outside the bounds of this lookup table.
This lack of input validation leads directly to an out-of-bounds read condition classified under CWE-125 Out-of-bounds Read. By indexing into memory locations immediately following the msg_size array, the system retrieves arbitrary data stored in adjacent read-only sections or potentially uninitialized memory regions depending on the build configuration and linker script layout. The severity of this flaw is significantly amplified because the retrieved out-of-bounds value is not merely discarded but is actively reused as a length parameter for subsequent operations. Specifically, the invalid size value gates a comparison against the count of received bytes in the message buffer. If the garbage value read from memory happens to be smaller than or equal to the actual packet length, the calculation cnt minus msg_size[type] yields a large positive integer representing an excessive byte budget. This inflated budget is then passed to the TLV Type-Length-Value post-receive handler function msg_tlv_post_recv().
The exploitation of this vulnerability allows for further memory corruption beyond simple information disclosure or crashes. The TLV processing loop utilizes the excessively large budget to iterate through message suffixes, performing in-place byte-swapping operations on data structures located well past the end of the allocated message slab. This constitutes a CWE-787 Out-of-bounds Write condition when the system attempts to modify memory it does not own. While the primary and most reliable impact observed is a denial of service resulting from segmentation faults or kernel panics due to accessing invalid memory addresses, the potential for arbitrary code execution exists if an attacker can control the adjacent memory contents sufficiently to influence the byte-swap operations in a predictable manner. However, given that the out-of-bounds data comes from fixed read-only sections in many embedded builds, the practical exploitability of remote code execution is limited compared to the certainty of system instability and crash.
From an operational perspective, this vulnerability presents a severe risk because it can be triggered remotely without authentication or prior interaction with the target device. The affected function ptp_msg_post_recv is invoked by ptp_port_event_gen which processes incoming frames via ptp_transport_recv. Since Precision Time Protocol typically operates over UDP multicast or raw Ethernet using EtherType 0x88F7, any host on the same local network segment can craft and send malicious PTP packets to trigger this flaw. This aligns with ATT&CK technique T1498 Network Denial of Service where an adversary disrupts availability by exploiting protocol implementation flaws. The attack requires no preconditions other than network connectivity to a node running Zephyr with CONFIG_PTP enabled, making it particularly dangerous in industrial control systems or IoT deployments that rely on precise time synchronization and may expose PTP interfaces to untrusted networks.
The remediation for this issue involves implementing strict input validation before array indexing occurs. The fix introduces an explicit check to ensure the extracted message type is less than the ARRAY_SIZE of msg_size, specifically rejecting types greater than thirteen with an error code indicating bad message format such as -EBADMSG. This prevents any out-of-bounds access by halting processing for invalid or reserved message types before they can influence memory operations. To mitigate this vulnerability in environments where patching is not immediately feasible, network administrators should restrict PTP traffic to trusted subnets using Access Control Lists on switches and routers. Additionally, disabling Precision Time Protocol support entirely if it is not required reduces the attack surface significantly. Long-term mitigation strategies include adopting static analysis tools that detect out-of-bounds array accesses during development and enforcing coding standards that mandate bounds checking for all inputs derived from external sources before they are used as indices or length parameters in memory operations.