CVE-2026-16512 in Zephyr
Zusammenfassung
von VulDB • 19.09.2026
gptp_handle_msg() in subsys/net/l2/ethernet/gptp/gptp.c dereferenziert den von GPTP_HDR() zurückgegebenen gPTP-Header und wertet hdr->message_type aus, ohne vorher zu prüfen, ob der empfangene Frame mindestens sizeof(struct gptp_hdr) (34) Bytes an Nutzdaten enthält. Der Header-Zugriff gptp_get_hdr() schlägt absichtlich nie für einen kurzen Puffer fehl – er gibt pkt->frags->data zurück und überlässt die Validierung den Aufrufern –, sodass ein abgeschnittener Frame zu einem Header-Pointer führt, der Speicherbereiche jenseits der empfangenen Daten abdeckt. Die nachfolgenden pro-Nachrichtentypen durchgeführten Prüfungen gleichen dies nicht aus: GPTP_VALID_LEN() reduziert sich auf len > 60, sobald der Ethernet-Header entfernt wurde, was für jede festgroße gPTP-Nachricht falsch ist; daher lehnt GPTP_CHECK_LEN() eine abgeschnittene SYNC-, FOLLOWUP-, PDELAY_RESP- oder SIGNALING-Nachricht niemals ab.
Der Fehler wird von einem nicht authentifizierten Peer im selben Link ausgelöst, der einen Ethernet-Frame mit ethertype 0x88F7 an die PTP-Multicast-Adresse einer Schnittstelle sendet, die als gPTP-Port konfiguriert ist und bei dem CONFIG_NET_GPTP aktiviert ist. Da konforme Ethernet-Frames auf 60 Bytes aufgefüllt werden, erfordert eine Nutzdatenlänge von weniger als 34 Bytes in der Regel einen Link, der Frames unterhalb der Mindestgröße übertragen kann – beispielsweise der native_sim TAP-Treiber (drivers/ethernet/eth_native_tap.c), der jede vom Host-Gerät bereitgestellte Länge weiterleitet, oder ein MAC, das auf die Annahme von zu kurzen Frames konfiguriert ist.
Das kurze Paket wird beibehalten (net_pkt_ref() in rcvd_sync_ptr, rcvd_follow_up_ptr, rcvd_pdelay_resp_ptr oder rcvd_announce_ptr) und später von den medienabhängigen und medienneutralen Zustandsautomaten in subsys/net/l2/ethernet/gptp/gptp_md.c und subsys/net/l2/ethernet/gptp/gptp_mi.c analysiert, die weitere Bytes lesen und einige davon (den announce-Prioritätsvektor, hdr->port_id) in einen Zustand kopieren, der anschließend übertragen wird. Unter dem standardmäßigen Allocator für festgroße Puffer (CONFIG_NET_BUF_FIXED_DATA_SIZE, Fragmente mit 128 Byte) bleiben die Zugriffe innerhalb des zugewiesenen Fragments und offenbaren veraltete Inhalte aus wiederverwendeten Puffern; unter dem experimentellen Allocator CONFIG_NET_BUF_VARIABLE_DATA_SIZE, bei dem Fragmente heap-basiert in der exakten Frame-Länge allokiert werden, handelt es sich um echte Out-of-Bounds-Lesezugriffe. Es gibt keine Schreiboperationen und keinen Verfügbarkeitsausfall (Availability Impact).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.