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

> An attacker on the same network link can trigger an out-of-bounds read in Zephyr's gPTP implementation, potentially disclosing stale memory contents.

- **Severity:** Low 3.1 (`CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 18 Sep 2026
- **Updated:** 18 Sep 2026
- **Also known as:** GHSA-89r6-q468-45xq

## What is CVE-2026-16512?

CVE-2026-16512 is a low-severity vulnerability in zephyrproject zephyr, published on 18 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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.

Weakness: CWE-125 (Out-of-bounds Read)

## Which versions are affected by CVE-2026-16512?


## How do I fix CVE-2026-16512?

No fix has been published for CVE-2026-16512 yet. Limit exposure of the affected software until one is available.

## Is CVE-2026-16512 being exploited?

There is no known exploitation of CVE-2026-16512 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-16512 and fix it if it is affected.

What it is: CVE-2026-16512 is a low-severity vulnerability in zephyrproject zephyr, published on 18 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-16512 in the wild and no public exploit code.

Affected product: zephyrproject zephyr. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-16512/ (Markdown: https://insights.sbomify.com/CVE-2026-16512/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-16512
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-16512
- OSV: https://osv.dev/vulnerability/CVE-2026-16512

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-16512/
Summaries are generated and may contain mistakes; the official description above is the record.