CVE-2026-16514 in Zephyr
Summary
by MITRE • 09/18/2026
gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->steps_removed (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.
The stack's only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes — so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() → gptp_handle_msg() → gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each — about 2 KB — beyond the end of the network buffer.
The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.
The fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability resides in the gptp_mi_qualify_announce function within the IEEE 802.1AS (gPTP) implementation of Zephyr RTOS, specifically affecting subsystems handling Time-Sensitive Networking and Audio Video Bridging deployments where CONFIG_NET_GPTP is enabled. This flaw constitutes a classic out-of-bounds read resulting from improper input validation and logic errors in processing the Path Trace TLV field of received Announce messages. The function iterates through clock identities listed in the Path Trace TLV to compare them against local system identifiers, but critically relies on an attacker-controlled wire field named steps_removed to determine the loop bound rather than the actual length of data contained within the Type-Length-Value structure itself. This discrepancy creates a scenario where the iteration count can vastly exceed the number of valid entries present in the packet buffer.
The technical root cause stems from the structural handling of network buffers and TLV parsing logic. The Path Trace TLV contains a flexible array member for clock identities, accessed via a raw pointer derived directly from the received frame data through the GPTP_ANNOUNCE macro. While there is an existing length validation function named GPTP_ANNOUNCE_CHECK_LEN that verifies the total payload size against tlv.len plus a fixed header offset of sixty-eight bytes, this check only ensures sufficient space for the declared TLV content. It does not constrain the loop variable steps_removed which dictates how many eight-byte clock identity entries are processed by memcmp operations inside the function. Consequently, if an attacker crafts a frame with tlv.len set to zero but sets steps_removed to its maximum accepted value of two hundred fifty-four, the validation passes because the payload length requirement is trivially met or bypassed depending on implementation specifics, yet the loop proceeds to execute hundreds of iterations beyond the actual data boundaries.
This logic error leads to a severe out-of-bounds read condition where the system attempts to access approximately two kilobytes of memory past the end of the allocated network buffer pool. The bytes accessed during this overread are utilized solely as operands for comparison operations and are not returned or exposed to the attacker, thereby mitigating risks associated with information disclosure such as kernel stack dumping or sensitive data leakage. However, the practical impact is a critical denial of service vulnerability. By triggering memory accesses into unmapped regions or areas protected by Memory Protection Unit configurations on embedded hardware, the fault causes an exception in the networking receive thread. This results in the termination or restart of the network processing subsystem, effectively disrupting all gPTP synchronization and potentially affecting other dependent services relying on stable network connectivity within the Time-Sensitive Networking domain.
The attack vector requires layer-two adjacency since IEEE 802.1AS Announce frames are transmitted to link-local multicast addresses and are not routed across subnets. An unauthenticated attacker positioned on the same Ethernet segment can exploit this flaw by sending a single malformed Announce frame with carefully crafted fields that trigger the out-of-bounds read. The vulnerability is classified under CWE-125 which describes Out-of-Bounds Read, indicating insufficient boundary checks when accessing memory buffers derived from external inputs. From an adversarial perspective aligned with MITRE ATT&CK frameworks, this behavior aligns with techniques involving resource exhaustion or denial of service through exploitation of software vulnerabilities that cause system crashes or instability without requiring authentication privileges.
Mitigation strategies primarily involve applying the upstream patch which corrects the loop bound calculation by deriving the true entry count from tlv.len divided by GPTP_CLOCK_ID_LEN rather than relying on steps_removed. The fix also introduces a validation check to reject any Announce message where steps_removed plus one exceeds the calculated number of valid entries, ensuring that iteration never proceeds beyond data proven present by prior length checks. For organizations deploying Time-Sensitive Networking or Audio Video Bridging solutions based on Zephyr RTOS, it is imperative to update to patched versions immediately if CONFIG_NET_GPTP is enabled in their build configurations. Additionally, network segmentation and strict ingress filtering at the switch level can provide defense-in-depth by dropping malformed gPTP frames before they reach vulnerable endpoints, although this does not replace the need for software remediation given the local nature of the attack requirement.