CVE-2026-82961

WysokieCVSS 7.8

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

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.13%

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

Streszczenie

Podatność w podsystemie GPIO systemu Zephyr polega na braku walidacji argumentu pin przekazywanego przez wątek użytkownika w funkcjach z_vrfy_gpio_pin_configure(), z_vrfy_gpio_pin_get_config() i z_vrfy_gpio_pin_interrupt_configure(). W buildach z CONFIG_USERSPACE=y pozwala to na zapis poza zakresem tablicy w pamięci jądra (m.in. wskaźnika funkcji) oraz odczyty poza zakresem i dostępy MMIO, co może prowadzić do korupcji pamięci jądra, wykonania dowolnego kodu lub awarii.

Ocena ryzyka

Wątek w trybie użytkownika z dostępem do obiektu urządzenia GPIO może wyjść z piaskownicy i uszkodzić pamięć jądra lub wykonać dowolny kod. Ryzyko dotyczy wyłącznie systemów zbudowanych z CONFIG_USERSPACE=y.

Rekomendacja

Zaktualizuj Zephyr do wersji zawierającej poprawkę walidującą pin względem gpio_driver_config.port_pin_mask oraz zakresu GPIO_MAX_PINS_PER_PORT. Jeśli aktualizacja nie jest możliwa, ogranicz przyznawanie wątkom użytkownika dostępu do obiektów urządzeń GPIO.

Powiązane podatności

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

The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller. z_vrfy_gpio_pin_configure(), z_vrfy_gpio_pin_get_config() and z_vrfy_gpio_pin_interrupt_configure() verified only the device object (K_SYSCALL_DRIVER_GPIO() / K_SYSCALL_OBJ()) and then passed the caller-supplied gpio_pin_t straight through to z_impl_gpio_pin_*() and on to the driver. The only pin check in include/zephyr/drivers/gpio.h was __ASSERT(gpio_port_pin_is_supported(cfg->port_pin_mask, pin), ...), which compiles to nothing unless CONFIG_ASSERT is enabled, so in a production build no check existed at all. GPIO drivers use pin as a shift count and as an array index on the documented assumption that it is a pin the controller supports. On STM32, for example, gpio_stm32_pin_interrupt_configure() turns pin into an EXTI line and stm32_gpio_intc_set_irq_callback() writes data->cb[line_num].cb and data->cb[line_num].data into a NUM_EXTI_LINES-entry array (default 16) in drivers/interrupt_controller/intc_gpio_stm32.c, guarded only by a compiled-out __ASSERT_NO_MSG(); the same function then reads exti_irq_table[line_num] and calls irq_enable() on the result. Other controllers index fixed-size per-pin configuration tables the same way — drivers/gpio/gpio_ite_it8xxx2_v2.c reads an MMIO base pointer out of wuc_base[8] with the caller's pin and performs a read-modify-write through it. The issue is reachable only in builds with CONFIG_USERSPACE=y (the file is compiled under that symbol), by a user-mode thread that has been granted access to a GPIO device object. Such a grant is intended to authorize control of that port's pins; the missing validation instead lets the thread drive a supervisor-mode out-of-bounds write of a function pointer and an associated void * past a kernel .bss array, and out-of-bounds reads that feed irq_enable() and MMIO accesses — an escape from the user-mode sandbox that can lead to kernel memory corruption, arbitrary code execution, or a crash. The fix validates pin against the controller's gpio_driver_config.port_pin_mask with gpio_port_pin_is_supported() in every pin-taking z_vrfy_ handler and returns -EINVAL otherwise, complemented by an unconditional pin >= GPIO_MAX_PINS_PER_PORT range check added to the shared z_impl_gpio_pin_*() inlines.

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