CVE-2026-14696
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 10 - wyżej niż 10% wszystkich znanych CVE
Streszczenie
Podatność w Zephyr RTOS powoduje wyciek buforów sieciowych (net_pkt) w przypadku włączenia mostkowania Ethernet (CONFIG_NET_ETHERNET_BRIDGE). Ramki z nierozpoznanym EtherType, dostarczane również do lokalnego stosu, są oznaczane jako NET_OK, co jest interpretowane jako ich zużycie, ale w rzeczywistości nie są zwalniane. Atakujący w segmencie L2 może wysłać zalew ramek broadcast/multicast z dowolnym EtherType, co prowadzi do wyczerpania puli buforów i trwałej odmowy usługi (DoS) do czasu restartu urządzenia.
Ocena ryzyka
Ryzyko polega na możliwości zdalnego wywołania trwałej odmowy usługi (DoS) na urządzeniu z włączonym mostkowaniem Ethernet. Atak nie wymaga uwierzytelnienia i może być przeprowadzony przez dowolne urządzenie w segmencie L2, co uniemożliwia dalszy odbiór ruchu do czasu restartu.
Rekomendacja
Zaleca się natychmiastowe zastosowanie poprawki dostarczonej przez producenta (Zephyr RTOS), która zmienia obsługę ramek w eth_bridge_handle_locally() tak, aby poprawnie propagować werdykt i zwalniać pakiety. Jeśli poprawka nie jest jeszcze dostępna, należy rozważyć wyłączenie mostkowania Ethernet lub ograniczenie zaufania do urządzeń w segmencie L2.
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)
When Ethernet bridging is enabled (CONFIG_NET_ETHERNET_BRIDGE), eth_bridge_input_process() in subsys/net/l2/ethernet/bridge/bridge_input.c decides how each frame received on a bridge member interface is handled. For frames that must also be delivered to the local stack, the code called eth_bridge_handle_locally() and returned NET_OK. That helper does not consume the packet — it only calls bridge_iface_recv() (via virtual_recv()), which returns NET_CONTINUE without taking ownership of pkt. The NET_OK verdict then propagates through ethernet_recv() up to processing_data() in subsys/net/ip/net_core.c, where NET_OK is interpreted as "the packet was consumed, do not free it." Because no consumer actually took ownership, the RX net_pkt is never returned to the pool and is leaked. The concretely reproducible leak occurs for frames whose EtherType has no registered L3 handler when CONFIG_NET_ETHERNET_FORWARD_UNRECOGNISED_ETHERTYPE is set (default y when CONFIG_NET_SOCKETS_PACKET is enabled): the fall-through L3 dispatch does not overwrite the NET_OK verdict, so ethernet_recv() returns NET_OK and the buffer is never released. Any device on a bridged L2 segment can emit broadcast/multicast frames carrying an arbitrary EtherType with no authentication. Each such frame permanently consumes one buffer from the finite RX pool (CONFIG_NET_PKT_RX_COUNT), so a brief broadcast flood exhausts the pool and the device can no longer receive traffic until it is rebooted — a persistent denial of service. There is no confidentiality or integrity impact. The fix makes eth_bridge_handle_locally() propagate the real net_verdict and return NET_CONTINUE for locally-kept frames, writing the bridge interface back through a new dst_iface out-parameter so the packet follows the normal receive path and is unreferenced exactly once.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS