CVE-2026-16512 Overview
CVE-2026-16512 is an out-of-bounds read [CWE-125] in the Zephyr RTOS generalized Precision Time Protocol (gPTP) stack. The gptp_handle_msg() function in subsys/net/l2/ethernet/gptp/gptp.c dereferences a gPTP header pointer before verifying the frame carries at least sizeof(struct gptp_hdr) (34) bytes of payload. An unauthenticated peer on the same Ethernet link can send a truncated frame with ethertype 0x88F7 to trigger the read. Subsequent state machines then copy fields from the malformed frame into state that is later retransmitted, potentially disclosing stale buffer contents.
Critical Impact
An adjacent-network attacker can trigger out-of-bounds reads in the gPTP stack, leading to information disclosure when the experimental variable-size buffer allocator is used.
Affected Products
- Zephyr RTOS with CONFIG_NET_GPTP enabled
- Zephyr builds using CONFIG_NET_BUF_VARIABLE_DATA_SIZE allocator (genuine out-of-bounds reads)
- Zephyr native_sim targets using the TAP driver in drivers/ethernet/eth_native_tap.c
Discovery Timeline
- 2026-09-18 - CVE-2026-16512 published to the National Vulnerability Database (NVD)
- 2026-09-18 - Last updated in NVD database
Technical Details for CVE-2026-16512
Vulnerability Analysis
The defect resides in gptp_handle_msg() within subsys/net/l2/ethernet/gptp/gptp.c. The function calls GPTP_HDR() to obtain a header pointer, then switches on hdr->message_type without validating the packet length. The accessor gptp_get_hdr() intentionally returns pkt->frags->data without failing on short buffers, deferring validation to callers that never perform it.
The per-message-type length check GPTP_VALID_LEN() reduces to len > 60 after the Ethernet header is pulled. This condition is false for every fixed-size gPTP message, so GPTP_CHECK_LEN() never rejects a truncated SYNC, FOLLOWUP, PDELAY_RESP, or SIGNALING frame. Short packets are retained via net_pkt_ref() into rcvd_sync_ptr, rcvd_follow_up_ptr, rcvd_pdelay_resp_ptr, or rcvd_announce_ptr and parsed later by state machines in gptp_md.c and gptp_mi.c.
Root Cause
The root cause is missing input validation on received gPTP frames. The header accessor delegates length checking to callers, but gptp_handle_msg() performs no bounds check before dereferencing the header. Downstream code reads and copies fields, including the announce priority vector and hdr->port_id, into state subsequently transmitted on the wire.
Attack Vector
Exploitation requires an unauthenticated attacker on the same Ethernet link as a gPTP-configured interface. The attacker sends a frame shorter than 34 bytes with ethertype 0x88F7 to the PTP multicast address. Because conformant Ethernet pads frames to 60 bytes, delivery of a sub-minimum frame requires a link that accepts undersized frames, such as the native_sim TAP driver or a MAC configured to accept runt frames. Under CONFIG_NET_BUF_VARIABLE_DATA_SIZE, the reads extend beyond the allocated heap fragment.
// Patch: check minimum packet length before header dereference
static void gptp_handle_msg(struct net_pkt *pkt)
{
if (GPTP_PACKET_LEN(pkt) < sizeof(struct gptp_hdr)) {
NET_DBG("gPTP packet too short (%zu)", GPTP_PACKET_LEN(pkt));
return;
}
struct gptp_hdr *hdr = GPTP_HDR(pkt);
struct gptp_pdelay_req_state *pdelay_req_state;
struct gptp_sync_rcv_state *sync_rcv_state;
Source: Zephyr commit 84eaf32c9301e911ad038a057f447a7836a2a2f8
Detection Methods for CVE-2026-16512
Indicators of Compromise
- Ethernet frames with ethertype 0x88F7 shorter than 34 bytes of payload arriving on gPTP-configured interfaces.
- gPTP announce messages carrying priority vector or port_id fields matching contents of previously freed network buffers.
- Debug log entries from Zephyr indicating gPTP packet too short after applying the patch.
Detection Strategies
- Monitor Layer 2 traffic on gPTP-enabled ports for frames below the 60-byte Ethernet minimum with ethertype 0x88F7.
- Inspect PTP announce and follow-up messages for anomalous or unstable priority vector values that may indicate leaked memory.
- Audit switch and MAC configurations for acceptance of runt frames on interfaces connected to Zephyr devices.
Monitoring Recommendations
- Enable link-layer packet capture on gPTP segments and alert on undersized 0x88F7 frames from unexpected sources.
- Track Zephyr device logs for NET_DBG messages related to gPTP packet handling.
- Review firmware build configurations to identify devices using CONFIG_NET_BUF_VARIABLE_DATA_SIZE, where the impact is greater.
How to Mitigate CVE-2026-16512
Immediate Actions Required
- Apply the upstream Zephyr patch that adds the GPTP_PACKET_LEN() check to gptp_handle_msg().
- Rebuild and redeploy Zephyr firmware for all devices with CONFIG_NET_GPTP enabled.
- Restrict gPTP-capable interfaces to trusted network segments where adjacent attacker access is limited.
Patch Information
The fix is available in Zephyr commit 84eaf32c9301e911ad038a057f447a7836a2a2f8, which adds an explicit length check prior to dereferencing the gPTP header. Details are documented in GitHub Security Advisory GHSA-89r6-q468-45xq and the Zephyr commit notification.
Workarounds
- Disable CONFIG_NET_GPTP on devices that do not require IEEE 802.1AS time synchronization.
- Configure MAC controllers and upstream switches to drop Ethernet frames shorter than the 60-byte minimum.
- Avoid deploying the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE allocator on gPTP-enabled builds until patched.
# Disable gPTP in Zephyr Kconfig if time synchronization is not needed
CONFIG_NET_GPTP=n
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

