CVE-2026-16514

ŚrednieCVSS 4.3

Opublikowano: 18/09/2026(UTC)Zaktualizowano: 18/09/2026(UTC)Przetłumaczono: 18/09/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.24%

Percentyl 15 - wyżej niż 15% wszystkich znanych CVE

Streszczenie

Funkcja gptp_mi_qualify_announce() w podsystemie gPTP systemu Zephyr przetwarza odebrane komunikaty Announce, porównując tożsamości zegarów. Pętla porównująca używa liczby kroków (steps_removed) sterowanej przez atakującego, zamiast rzeczywistej liczby wpisów w TLV, co prowadzi do odczytu poza buforem sieciowym. Atakujący w tej samej sieci L2 może wysłać jeden ramkę, powodując odczyt około 2 KB poza buforem i potencjalnie wywołując denial of service przez zablokowanie wątku RX.

Ocena ryzyka

Ryzyko obejmuje denial of service w systemach wykorzystujących opcjonalny moduł CONFIG_NET_GPTP (TSN/AVB). Atak wymaga dostępu do warstwy 2, ale nie wymaga uwierzytelnienia, przez co może zakłócić działanie krytycznych systemów czasu rzeczywistego.

Rekomendacja

Należy zastosować poprawkę, która ogranicza liczbę odczytów do faktycznej liczby wpisów w TLV (tlv.len / 8). Jeśli nie jest to możliwe, należy wyłączyć moduł CONFIG_NET_GPTP w środowiskach, gdzie nie jest niezbędny.

Inne podatności w Zephyr RTOS

Zobacz wszystkie

Oryginalny opis (angielski, źródło NVD)

gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->steps_removed (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame. The stack's only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes — so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() → gptp_handle_msg() → gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each — about 2 KB — beyond the end of the network buffer. The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed. The fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS