CVE-2026-16514: Out-of-bounds read in gPTP Announce path-trace validation via unvalidated stepsRemoved
gptpmiqualifyannounce() in subsys/net/l2/ethernet/gptp/gptpmi.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->stepsremoved (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because pathsequence is the flexible member of the wire TLV (struct gptppathtracetlv) and GPTPANNOUNCE() 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, GPTPANNOUNCECHECKLEN(), 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 stepsremoved = 254; the frame passes the length check and reception path (netgptprecv() → gptphandlemsg() → gptpmiqualifyannounce()), 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 CONFIGNETGPTP (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 / GPTPCLOCKIDLEN and rejects the announce when stepsremoved + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable the opt-in experimental gPTP support (CONFIG_NET_GPTP) to prevent the vulnerable announce/path-trace validation code path from being reachable on affected TSN/AVB builds.
Linux kernel CONFIG_NET_GPTP CONFIG_NET_GPTP = disable - Compensating control
Reduce exposure by preventing layer-2 adjacency/traffic on the same Ethernet segment for untrusted systems (gPTP frames are link-local multicast and not routed, so L2 access control/segmentation limits attacker reachability).
- Operational
Monitor for networking RX thread faults/DoS events associated with gPTP Announce handling, and restart networking services/affected interfaces if the RX thread crashes before the fix is applied.
Event History
Frequently Asked Questions
Which systems are exposed to exploitation?
Systems that process received gPTP IEEE 802.1AS Announce messages are exposed when an attacker can send frames from the same Ethernet segment. The affected receive path performs no authentication for these messages.
What does an attacker need to send?
An unauthenticated attacker can trigger the condition with a single crafted Announce frame. The described example uses a Path Trace TLV with tlv.len set to 0 and steps_removed set to 254, causing the handler to read beyond the received frame.