---
id: "CVE-2026-82961"
kind: "vulnerability"
aliases: ["CVE-2026-82961"]
title: "Zephyr: GPIO syscalls skip pin validation, letting user threads write kernel memory"
severity: "high"
cvss: 7.8
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded", "gpio", "runtime", "stm32", "user-mode", "zephyr"]
not_affected_if: ["kernel-only-threads", "no-gpio-grant", "no-userspace"]
published_at: "2026-10-28T17:18:43+00:00"
first_seen_at: "2026-10-28T17:34:10+00:00"
updated_at: "2026-10-28T17:36:17+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82961", "first_seen_at": "2026-10-28T17:34:10+00:00"}]
---

# Zephyr: GPIO syscalls skip pin validation, letting user threads write kernel memory

Zephyr's GPIO syscall handlers pass a caller-supplied pin number straight to the driver without checking it, and the only check is compiled out in production builds. A user-mode thread with access to a GPIO device can use this to write out of bounds in kernel memory, escaping the user-mode sandbox toward code execution or a crash.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the build sets `CONFIG_USERSPACE=y` and whether user-mode threads are granted access to GPIO device objects
- Check whether `drivers/gpio/gpio_handlers.c` in your Zephyr tree contains a `gpio_port_pin_is_supported()` check in `z_vrfy_gpio_pin_configure()`
- Check the Zephyr version in use against the fixed release, unknown from the sources

## Fix

- Zephyr: move to the release that includes the fix for CVE-2026-82961 (fixed version unknown from the sources)
- Until patched, avoid granting user-mode threads access to GPIO device objects

## Timeline

- 2026-10-28T17:34:10+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-82961

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_