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-16514Średnie
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.
- CVE-2026-16512Niskie
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.
- CVE-2026-13480Niskie
Podatność w obsłudze fragmentów danych LoRaWAN TS004 w Zephyr RTOS (subsys/lorawan/services/frag_transport.c) polega na braku walidacji długości pozostałych bajtów przed odczytem w handlerze frag_transport_package_callback(). Atakujący, znający klucze sesyjne, może spowodować odczyt poza buforem RxPayload (do ~232 bajtów), kopiując dane z pamięci statycznej do buforów dekodera i obrazu FUOTA.
- CVE-2026-13213Średnie
Podatność w usłudze Hearing Access Service (HAS) w Zephyr RTOS pozwala zdalnie (przez Bluetooth) wywołać awarię (crash) urządzenia peryferyjnego HAS. Problem występuje, gdy wcześniej sparowany klient łączy się ponownie w oknie czasowym przed rejestracją usługi przez aplikację, co prowadzi do asercji lub dereferencji pustego wskaźnika.
- CVE-2026-12633Wysokie
Podatność w kodzie obsługi sąsiedztwa IPv6 (subsys/net/ip/ipv6_nbr.c) w Zephyr RTOS. Funkcja handle_ra_6co() nie ogranicza pola context_len z opcji 6CO w komunikatach Router Advertisement, co prowadzi do przepełnienia bufora i zapisu poza pamięcią (memset). Atakujący z tej samej sieci może wysłać spreparowany pakiet, powodując awarię systemu.
- CVE-2026-9771Wysokie
Podatność w wywołaniu systemowym flash_copy() w Zephyr RTOS (z włączonym CONFIG_USERSPACE) pozwala nieuprzywilejowanemu wątkowi na przekazanie sfałszowanych wskaźników do struktur urządzeń flash. Brak walidacji obiektów urządzeń (src_dev, dst_dev) przed dereferencją umożliwia wywołanie dowolnego kodu w trybie nadzorcy, co prowadzi do eskalacji uprawnień poza piaskownicę użytkownika.
- CVE-2026-12364Wysokie
Podatność w Zephyr RTOS dotyczy weryfikatora wywołań systemowych z_vrfy_z_log_msg_static_create(), który nie sprawdzał argumentów przekazywanych do funkcji jądra. Umożliwia to nieuprzywilejowanemu wątkowi użytkownika przekazanie dowolnych wskaźników i długości, co prowadzi do odczytu pamięci jądra i awarii systemu.
- CVE-2026-12363Średnie
Podatność w usłudze transportu bloków danych LoRaWAN (frag_transport.c) nie sprawdza licznika fragmentów w odebranej komendzie DATA_FRAGMENT przed przekazaniem jej do dekodera. Wartość frag_counter równa 0 powoduje niedomiar arytmetyki (frag_counter - 1), co prowadzi do zapisu poza zakresem (CWE-787) w domyślnym dekoderze Semtech/LoRaMAC-node, uszkadzając stan dekodera i przerywając sesję aktualizacji oprogramowania (FUOTA).
- CVE-2026-12233Średnie
Podatność w backendzie PSA Protected Storage dla poświadczeń TLS (subsys/net/lib/tls_credentials/tls_credentials_trusted.c) polega na niezainicjalizowanym mutexie (k_mutex) — zadeklarowanym jako statyczna struktura wypełniona zerami, bez wywołania k_mutex_init(). Przy braku rywalizacji o blokadę działa to poprawnie, ale przy jednoczesnym dostępie z dwóch wątków dochodzi do wyłuskania pustego wskaźnika (NULL) w kolejce oczekujących, co powoduje panikę jądra i reset urządzenia.
- CVE-2026-11812Niskie
Podatność w podsystemie UpdateHub (subsys/mgmt/updatehub/updatehub.c) polega na braku synchronizacji dostępu do współdzielonej struktury ctx. Jednoczesne operacje (tło autohandlera i wywołania użytkownika) mogą zapisać poza tablicą fds[1], nadpisując sąsiednie pola struktury, co prowadzi do uszkodzenia stanu wewnętrznego i odmowy usługi w ścieżce aktualizacji oprogramowania.
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