Zephyr RTOS CVE-2026-82961

Requires a build with CONFIG_USERSPACE=y (the vulnerable drivers/gpio/gpio_handlers.c is compiled only under that symbol); builds without userspace memory protection are not affected. The attacker must already be a user-mode thread that has been granted access to a specific GPIO device object (via k_object_access_grant / the thread's memory domain) - the grant intended to authorize that port's pins. Exposure is worsened when CONFIG_ASSERT is disabled (typical for production), because the only pre-fix pin guard was a compiled-out __ASSERT. Exposed, released entry points are gpio_pin_configure(), gpio_pin_get_config() and gpio_pin_interrupt_configure(); the five further pin syscalls hardened by the fix only became syscalls after v4.4.0 and are in no release. Impact magnitude is driver/SoC-dependent (e.g. STM32 EXTI 16-line callback array, ITE it8xxx2 8-entry wuc_base MMIO-pointer table, gpio_emul flags[] on qemu_x86_64). Limiting factors: local access only (no network vector), a pre-existing legitimate GPIO object grant, and the CONFIG_USERSPACE build gate.

CVSS 7.8 (HIGH) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H describes a local, low-privilege, no-interaction out-of-bounds write (CWE-787) with full confidentiality, integrity and availability impact - consistent with the described kernel memory corruption and possible arbitrary code execution. This is a sandbox-escape / privilege-escalation primitive, NOT a remote-entry flaw: the attacker must already be executing as a user-mode thread on the device and must already hold a grant to a GPIO device object. EPSS is not provided and the issue is not in CISA KEV (no confirmed active exploitation), so there is no signal of widespread opportunistic exploitation; the vuln.today decision label is 'this_week' rather than act_now/emergency. A working PoC is embedded in the GHSA advisory (reporter reproduced a pin=64 OOB write on qemu_x86_64), which raises practical risk for affected builds. The dominant mitigating factor, stated in the evidence, is the build gate: the vulnerable code compiles only under CONFIG_USERSPACE=y, and the only legacy guard was an __ASSERT that is compiled out unless CONFIG_ASSERT is enabled - so production, userspace-isolated builds are precisely the exposed configuration. Net: a real and credible priority for the subset of Zephyr products that enable userspace memory protection and expose GPIO objects to untrusted threads, but low real-world risk for the majority of Zephyr deployments that do not build with CONFIG_USERSPACE=y. No data conflicts; the main gap is the absence of EPSS and the fact that the fixed version (4.5.0) is a projection, not a confirmed release.

On a device built with CONFIG_USERSPACE=y, a low-privilege user-mode thread that has legitimately been granted access to a GPIO device object calls the public API gpio_pin_configure() (or gpio_pin_interrupt_configure()) with an out-of-range pin index such as 64; the syscall handler validates only the device object and passes the pin through, and the driver uses it as an array index/shift, producing a supervisor-mode out-of-bounds write of a callback function pointer and void* past a kernel .bss array (e.g. the STM32 EXTI callback table) leading to kernel memory corruption or code execution. A public PoC reference is included in the GHSA advisory and was reproduced on qemu_x86_64. Because AV:L/AC:L/PR:L/UI:N, exploitation is straightforward once the attacker already runs a granted user thread, but it is local-only and cannot be reached over a network.