{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-82961 in the wild and no public exploit code.","fix":"No fix has been published for CVE-2026-82961 yet. Limit exposure of the affected software until one is available.","what":"CVE-2026-82961 is a high-severity vulnerability in zephyrproject zephyr, published on 28 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-82961 and fix it if it is affected.\n\nWhat it is: CVE-2026-82961 is a high-severity vulnerability in zephyrproject zephyr, published on 28 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-82961 in the wild and no public exploit code.\n\nAffected product: zephyrproject zephyr. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-82961/ (Markdown: https://insights.sbomify.com/CVE-2026-82961/index.md)","id":"CVE-2026-82961","markdown":"https://insights.sbomify.com/CVE-2026-82961/index.md","name":"CVE-2026-82961","record":{"aliases":["GHSA-4f2x-8qw8-jjgf"],"analysis":null,"analysis_generated_by":null,"assigner":"zephyr","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-787","name":"Out-of-bounds Write"}],"description":"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-\u003eport_pin_mask, pin), ...), which compiles to nothing unless CONFIG_ASSERT is enabled, so in a production build no check existed at all.\n\nGPIO 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-\u003ecb[line_num].cb and data-\u003ecb[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.\n\nThe 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.\n\nThe 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 \u003e= GPIO_MAX_PINS_PER_PORT range check added to the shared z_impl_gpio_pin_*() inlines.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":false,"headline":"Unvalidated pin index in GPIO syscall handlers allows out-of-bounds kernel writes from user mode","id":"CVE-2026-82961","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":5,"next":{"headline":"Out-of-bounds write in Zephyr Ethernet L2 when adding the link-layer header to a forwarded packet","id":"CVE-2026-82962"},"packages":[],"prev":{"headline":"Code injection in Eclipse Ditto","id":"CVE-2026-82958"},"products":["zephyr"],"published":"2026-10-28","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-28","vendors":["zephyrproject"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-82961/"}