CVE-2026-16513

WysokieCVSS 7.8

Opublikowano: 28/09/2026(UTC)Zaktualizowano: 27/10/2026(UTC)Przetłumaczono: 01/10/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.17%

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

Streszczenie

Podatność w weryfikatorze syscall RTIO w Zephyr RTOS (przed v4.3.0) pozwala nieuprzywilejowanemu wątkowi użytkownika zapisać wskaźnik do kontrolowanych danych pod dowolnym adresem jądra. Brakuje sprawdzenia K_SYSCALL_MEMORY_WRITE dla parametru wyjściowego handle, co umożliwia eskalację uprawnień do trybu jądra.

Ocena ryzyka

Atakujący może nadpisać wskaźniki funkcji jądra, struktury wątków lub tablice partycji pamięci, co prowadzi do pełnego przejęcia systemu lub jego awarii. Narusza to izolację zapewnianą przez CONFIG_USERSPACE.

Rekomendacja

Zaktualizuj Zephyr RTOS do wersji 4.3.0 lub nowszej, która zawiera poprawkę dodającą walidację zapisu dla parametru handle. Jeśli aktualizacja nie jest możliwa, ogranicz dostęp do obiektów RTIO tylko zaufanym wątkom.

Inne podatności w Zephyr RTOS

Zobacz wszystkie

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

The userspace verifier z_vrfy_rtio_sqe_copy_in_get_handles() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed *handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no K_SYSCALL_MEMORY_WRITE check in front of it. Any user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIG_USERSPACE and CONFIG_RTIO are affected; without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged. The write address is fully attacker-chosen and the written value is a pointer into the caller's own RTIO ring, whose contents the caller controls (the following *sqe = sqes[i] copies an attacker-supplied struct rtio_sqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIG_USERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemu_x86: a K_USER thread changed a supervisor global from NULL to a live kernel SQE pointer. The fix adds K_SYSCALL_MEMORY_WRITE(handle, sizeof(*handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread's writable memory domain or the thread is terminated by K_OOPS. The neighbouring verifier z_vrfy_rtio_cqe_get_mempool_buffer(), which checked its buff/buff_len out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 ("rtio: syscalls: validate output params as writable"); that residual was materially weaker, since a read check still confines the target to the caller's own memory domain.

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