CVE-2026-16512: bounds in zephyrproject zephyr
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.
AI Analysis
Technical Summary
The vulnerability arises because gptp_handle_msg() dereferences the gPTP header returned by GPTP_HDR() without verifying that the received Ethernet frame contains at least the size of the gPTP header (34 bytes). The header accessor gptp_get_hdr() always returns a pointer without failure, leaving validation to callers. Subsequent length checks do not reject truncated messages due to the logic in GPTP_VALID_LEN() and GPTP_CHECK_LEN(). An unauthenticated peer on the same link can send a short Ethernet frame with ethertype 0x88F7 to the PTP multicast address, causing the system to parse and copy data from beyond the actual frame length. Depending on the buffer allocator configuration, this results in either stale buffer content disclosure or genuine out-of-bounds reads. No writes or availability impacts occur.
Potential Impact
The impact is limited to information disclosure through out-of-bounds reads of memory beyond the received frame data. There is no ability to write memory or cause denial of service. The vulnerability requires an unauthenticated attacker on the same network link and a link capable of delivering undersized Ethernet frames. The CVSS score is 3.1 (low severity) reflecting limited confidentiality impact and high attack complexity.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a patch is available, users should consider disabling CONFIG_NET_GPTP if not required or ensure that network interfaces do not accept undersized Ethernet frames. Monitoring for updates from the Zephyr project is recommended.
CVE-2026-16512: bounds in zephyrproject zephyr
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.
CVSS v3.1
Score 3.1low
Affected software
zephyrproject
zephyr
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises because gptp_handle_msg() dereferences the gPTP header returned by GPTP_HDR() without verifying that the received Ethernet frame contains at least the size of the gPTP header (34 bytes). The header accessor gptp_get_hdr() always returns a pointer without failure, leaving validation to callers. Subsequent length checks do not reject truncated messages due to the logic in GPTP_VALID_LEN() and GPTP_CHECK_LEN(). An unauthenticated peer on the same link can send a short Ethernet frame with ethertype 0x88F7 to the PTP multicast address, causing the system to parse and copy data from beyond the actual frame length. Depending on the buffer allocator configuration, this results in either stale buffer content disclosure or genuine out-of-bounds reads. No writes or availability impacts occur.
Potential Impact
The impact is limited to information disclosure through out-of-bounds reads of memory beyond the received frame data. There is no ability to write memory or cause denial of service. The vulnerability requires an unauthenticated attacker on the same network link and a link capable of delivering undersized Ethernet frames. The CVSS score is 3.1 (low severity) reflecting limited confidentiality impact and high attack complexity.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a patch is available, users should consider disabling CONFIG_NET_GPTP if not required or ensure that network interfaces do not accept undersized Ethernet frames. Monitoring for updates from the Zephyr project is recommended.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-07-21T21:42:57.327Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6aad6b0955bf5e2cf5419293
Added to database: 09/18/2026, 16:47:05 UTC
Last enriched: 09/18/2026, 17:02:06 UTC
Last updated: 09/19/2026, 01:07:00 UTC
Views: 9
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.