CVE-2026-16512
NiskieCVSS 3.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 12 - wyżej niż 12% wszystkich znanych CVE
Streszczenie
Funkcja gptp_handle_msg() w Zephyr RTOS nie sprawdza długości odebranej ramki przed dereferencją wskaźnika do nagłówka gPTP. Skrócona ramka może prowadzić do odczytu poza przydzielonym buforem, co ujawnia zawartość pamięci.
Ocena ryzyka
Nieuwierzytelniony nadawca w tej samej sieci może wysłać specjalnie spreparowaną ramkę Ethernet, powodując wyciek danych z pamięci urządzenia. Może to umożliwić wykradzenie poufnych informacji, choć nie ma wpływu na integralność ani dostępność.
Rekomendacja
Zaleca się natychmiastową aktualizację Zephyr RTOS do wersji, w której poprawiono walidację długości ramki w gPTP. Jeśli nie jest to możliwe, należy wyłączyć gPTP na zaufanych interfejsach lub zastosować filtr ruchu.
Inne podatności w Zephyr RTOS
Zobacz wszystkie- CVE-2026-90585Średnie
Sterownik UART SCI Renesas RA w Zephyr nie potwierdza warunku błędu odbioru w procedurze obsługi przerwania uart_ra_sci_eri_isr(), gdy nie zarejestrowano callbacku (data->user_cb jest NULL). Flagi błędów SCI pozostają ustawione, a flaga przerwania ICU nie jest czyszczona, co powoduje natychmiastowe ponowne wejście w ISR w nieskończonej pętli. Problem występuje przy CONFIG_UART_INTERRUPT_DRIVEN=y i CONFIG_UART_ASYNC_API=n, gdy przerwanie błędu zostanie odmaskowane przez uart_configure() lub uart_irq_err_enable().
- CVE-2026-87043Średnie
W generatorze liczb losowych opartym na urządzeniu entropii (subsys/random/random_entropy_device.c) funkcja rand_get() zwracała wcześnie błąd -ENODEV, gdy urządzenie nie było gotowe, pomijając awaryjny mechanizm oparty na timerze systemowym. Ponieważ funkcje sys_rand_get() i sys_rand32_get() zwracają void i nie raportują błędu, bufor wyjściowy pozostawał niezmieniony, a jego wcześniejsza zawartość (niezainicjalizowana pamięć) była zwracana jako dane losowe. Stan "niegotowości" jest normalnym warunkiem działania (np. wczesna inicjalizacja) lub trwałym skutkiem błędu inicjalizacji sterownika entropii.
- CVE-2026-87041Wysokie
Podatność w mechanizmie weryfikacji kolejki zgłoszeń RTIO (rtio_vrfy_sqe()) w Zephyr RTOS polega na błędnym użyciu operatora &= z makrem K_SYSCALL_MEMORY(), które zwraca wartość niezerową przy błędzie. W efekcie sprawdzenia uprawnień do buforów działały odwrotnie: niedostępne bufory były akceptowane, a prawidłowe bufory powodowały oops jądra. Umożliwia to wątkom użytkownika z przydzielonym kontekstem RTIO zapis do dowolnej pamięci jądra, jej ujawnienie lub wywołanie błędu, co stanowi obejście izolacji CONFIG_USERSPACE.
- CVE-2026-87039Wysokie
Podatność w mechanizmie weryfikacji wywołań systemowych Zephyr RTOS (funkcja z_vrfy_i2s_configure) polega na pominięciu sprawdzenia własności i typu obiektu mem_slab oraz weryfikacji block_size, gdy frame_clk_freq wynosi 0. W efekcie nieuprzywilejowany wątek działający w CONFIG_USERSPACE może przekazać dowolny wskaźnik, który trafia do kodu sterownika (np. i2s_litex) i jest używany w kontekście jądra przez k_mem_slab_alloc()/k_mem_slab_free().
- CVE-2026-16511Wysokie
Dwie funkcje weryfikujące wywołania systemowe RTIO w Zephyr RTOS nie sprawdzały poprawnie wskaźników dostarczonych przez użytkownika przed zapisem do pamięci jądra. z_vrfy_rtio_sqe_cancel() w ogóle nie walidowała wskaźnika, pozwalając wątkowi użytkownika na ustawienie wybranych bitów w pamięci jądra, a z_vrfy_rtio_sqe_copy_in_get_handles() zapisywała wskaźnik jądra pod dowolny adres bez sprawdzenia prawa zapisu. Luki dotyczą wyłącznie systemów zbudowanych z CONFIG_USERSPACE i CONFIG_RTIO.
- CVE-2026-82962Średnie
Podatność w funkcji ethernet_fill_header() w stosie sieciowym Zephyr RTOS polega na tym, że nagłówek Ethernet jest wstawiany w miejscu (poprzez net_buf_push) bez sprawdzenia, czy pakiet ma wystarczający zapas miejsca (headroom). Pakiety przydzielone przez inny stos L2 (np. 802.15.4/OpenThread, PPP) i przekazane do Ethernetu w wyniku routingu lub tunelowania mają zbyt mały headroom, co prowadzi do zapisu poza granicami bufora. W buildach bez CONFIG_ASSERT i CONFIG_NET_BUF_HARDENING powoduje to korupcję pamięci.
- CVE-2026-19595Średnie
Podatność w mechanizmie weryfikacji wywołań systemowych Zephyr RTOS: funkcja z_vrfy_rtio_cqe_get_mempool_buffer() sprawdzała parametry wyjściowe buff i buff_len za pomocą K_SYSCALL_MEMORY_READ() zamiast K_SYSCALL_MEMORY_WRITE(). Umożliwia to nieuprzywilejowanemu wątkowi w trybie użytkownika wywołanie wywołania systemowego ze wskaźnikami do pamięci tylko do odczytu, co prowadzi do zapisu w trybie nadzorcy poza dozwolonym obszarem lub do błędu jądra i zatrzymania/restartu urządzenia.
- CVE-2026-19940Średnie
Podatność w implementacji Bluetooth Classic Hands-Free Profile Audio Gateway (HFP AG) w Zephyr RTOS powoduje uszkodzenie listy timeoutów jądra. Poprzez wysłanie AT+CIND? i szybkie ponowne połączenie, zdalny atakujący może wywołać zawieszenie lub awarię całego systemu.
- CVE-2026-19736Wysokie
Sterownik entropii NXP MCUX TRNG w Zephyrze (drivers/entropy/entropy_mcux_trng.c) przekazuje liczbę bajtów żądania bezpośrednio do funkcji SDK TRNG_GetRandomData(), która w przypadku układów i.MX RT5xx/RT6xx zawsze kopiuje całe 32-bitowe słowa i zaokrągla pobieranie entropii do wielokrotności 128 bajtów. Przy długości niebędącej wielokrotnością czterech dochodzi do przepełnienia bufora o maksymalnie 127 bajtów, co może prowadzić do uszkodzenia pamięci jądra lub stosu.
- CVE-2026-19575Wysokie
Podatność w Zephyr RTOS dotyczy handlera trybu użytkownika z_vrfy_device_deinit() w kernel/device.c, który walidował argument dev za pomocą K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). Ponieważ k_object_validate() pomija porównanie typu dla K_OBJ_ANY, sprawdzenie ograniczało się do tego, czy wskaźnik należy do dowolnego obiektu jądra, do którego wątek ma uprawnienia — bez weryfikacji rzeczywistego typu obiektu. Umożliwia to lokalnemu wątkowi w trybie użytkownika przekazanie obiektu stosu wątku (np. z k_thread_stack_alloc()) i wykonanie kodu jądra w trybie supervisora.
Oryginalny opis (angielski, źródło NVD)
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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS