Description
gptp_handle_msg() in subsys/net/l2/ethernet/gptp/gptp.c dereferenced the gPTP header returned by GPTP_HDR() and switched on hdr->message_type without first checking that the received frame carries at least sizeof(struct gptp_hdr) (34) bytes of payload. The header accessor gptp_get_hdr() 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: GPTP_VALID_LEN() reduces to len > 60 once the Ethernet header has been pulled, which is false for every fixed-size gPTP message, so GPTP_CHECK_LEN() never rejects a truncated SYNC, FOLLOWUP, PDELAY_RESP 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 CONFIG_NET_GPTP 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 native_sim TAP driver (drivers/ethernet/eth_native_tap.c), which forwards whatever length the host device supplies, or a MAC configured to accept undersized frames.

The short packet is retained (net_pkt_ref() into rcvd_sync_ptr, rcvd_follow_up_ptr, rcvd_pdelay_resp_ptr or rcvd_announce_ptr) and later parsed by the media-dependent and media-independent state machines in subsys/net/l2/ethernet/gptp/gptp_md.c and subsys/net/l2/ethernet/gptp/gptp_mi.c, which read tens of further bytes and copy some of them (the announce priority vector, hdr->port_id) into state that is subsequently transmitted. Under the default fixed-size buffer allocator (CONFIG_NET_BUF_FIXED_DATA_SIZE, 128-byte fragments) the accesses stay inside the allocated fragment and disclose stale recycled buffer contents; under the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE 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.
Published: 2026-09-18
Score: 3.1 Low
EPSS: < 1% Very Low
KEV: No
Impact: Memory disclosure
Action: Patch
AI Analysis

Impact

An out‑of‑bounds read occurs in the gPTP receive routine when a short Ethernet frame is processed. The header pointer returned by GPTP_HDR() is dereferenced without ensuring the payload is at least 34 bytes, causing the code to read beyond the bounds of the received packet. The flaw manifests as a memory disclosure of stale or unrelated data; there is no write, crash, or denial of service. The weakness corresponds to CWE‑125.

Affected Systems

The vulnerability affects devices running the Zephyr RTOS with CONFIG_NET_GPTP enabled on a network interface configured as a gPTP port. An attacker must be able to send Ethernet frames of type 0x88F7 to the PTP multicast address, and the link must accept undersized frames (e.g., a TAP driver or a MAC that permits frames shorter than the minimum Ethernet payload).

Risk and Exploitability

The CVSS score of 3.1 indicates a low severity, and the EPSS score of less than 1% indicates a very low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. An unauthenticated peer on the same network link can send a crafted short frame to trigger the read, provided the interface is listening for GPTP frames and the link allows sub‑minimum frames. The impact is the leakage of memory contents; there is no escalation or denial of service. The attack is straightforward for an attacker with network access to the device.

Generated by OpenCVE AI on September 19, 2026 at 18:10 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Zephyr to a version that contains the commit 84eaf32c9301e911ad038a057f447a7836a2a2f8 resolving the out‑of‑bounds read.
  • If an upgrade is not possible, disable CONFIG_NET_GPTP or otherwise prevent the device from receiving GPTP frames on the vulnerable interface.
  • Configure the network interface or link to enforce the Ethernet minimum frame size and block frames with ethertype 0x88F7 from reaching the device.

Generated by OpenCVE AI on September 19, 2026 at 18:10 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 00:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Fri, 18 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Fri, 18 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Description gptp_handle_msg() in subsys/net/l2/ethernet/gptp/gptp.c dereferenced the gPTP header returned by GPTP_HDR() and switched on hdr->message_type without first checking that the received frame carries at least sizeof(struct gptp_hdr) (34) bytes of payload. The header accessor gptp_get_hdr() 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: GPTP_VALID_LEN() reduces to len > 60 once the Ethernet header has been pulled, which is false for every fixed-size gPTP message, so GPTP_CHECK_LEN() never rejects a truncated SYNC, FOLLOWUP, PDELAY_RESP 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 CONFIG_NET_GPTP 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 native_sim TAP driver (drivers/ethernet/eth_native_tap.c), which forwards whatever length the host device supplies, or a MAC configured to accept undersized frames. The short packet is retained (net_pkt_ref() into rcvd_sync_ptr, rcvd_follow_up_ptr, rcvd_pdelay_resp_ptr or rcvd_announce_ptr) and later parsed by the media-dependent and media-independent state machines in subsys/net/l2/ethernet/gptp/gptp_md.c and subsys/net/l2/ethernet/gptp/gptp_mi.c, which read tens of further bytes and copy some of them (the announce priority vector, hdr->port_id) into state that is subsequently transmitted. Under the default fixed-size buffer allocator (CONFIG_NET_BUF_FIXED_DATA_SIZE, 128-byte fragments) the accesses stay inside the allocated fragment and disclose stale recycled buffer contents; under the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE 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.
Title Out-of-bounds read in the Zephyr gPTP receive path when handling short Ethernet frames
Weaknesses CWE-125
References
Metrics cvssV3_1

{'score': 3.1, 'vector': 'CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-09-18T16:43:25.580Z

Reserved: 2026-07-21T21:42:57.327Z

Link: CVE-2026-16512

cve-icon Vulnrichment

Updated: 2026-09-18T16:43:20.336Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-09-18T15:17:05.603

Modified: 2026-09-18T19:11:57.760

Link: CVE-2026-16512

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T18:15:02Z

Weaknesses