CVE-2026-16512: Out-of-bounds read in the Zephyr gPTP receive path when handling short Ethernet frames

gptphandlemsg() in subsys/net/l2/ethernet/gptp/gptp.c dereferenced the gPTP header returned by GPTPHDR() and switched on hdr->messagetype without first checking that the received frame carries at least sizeof(struct gptphdr) (34) bytes of payload. The header accessor gptpgethdr() deliberately never fails for a short buffer — it returns pkt->frags->data and leaves validation to its callers — so a truncated frame produced a header pointer covering memory beyond the received data. The per-message-type checks that follow do not compensate: GPTPVALIDLEN() reduces to len > 60 once the Ethernet header has been pulled, which is false for every fixed-size gPTP message, so GPTPCHECKLEN() never rejects a truncated SYNC, FOLLOWUP, PDELAYRESP or SIGNALING message.

The defect is reached by an unauthenticated peer on the same link sending an Ethernet frame with ethertype 0x88F7 to the PTP multicast address on an interface configured as a gPTP port, with CONFIGNETGPTP enabled. Because conformant Ethernet pads frames to 60 bytes, a payload shorter than 34 bytes generally requires a link that can deliver sub-minimum frames — for example the nativesim TAP driver (drivers/ethernet/ethnativetap.c), which forwards whatever length the host device supplies, or a MAC configured to accept undersized frames.

The short packet is retained (netpktref() into rcvdsyncptr, rcvdfollowupptr, rcvdpdelayrespptr or rcvdannounceptr) and later parsed by the media-dependent and media-independent state machines in subsys/net/l2/ethernet/gptp/gptpmd.c and subsys/net/l2/ethernet/gptp/gptpmi.c, which read tens of further bytes and copy some of them (the announce priority vector, hdr->portid) into state that is subsequently transmitted. Under the default fixed-size buffer allocator (CONFIGNETBUFFIXEDDATASIZE, 128-byte fragments) the accesses stay inside the allocated fragment and disclose stale recycled buffer contents; under the experimental CONFIGNETBUFVARIABLEDATASIZE allocator, where fragments are heap-allocated at the exact frame length, they are genuine out-of-bounds reads. There is no write and no availability impact.