Zephyr RTOS CVE-2026-19676

Exploitation requires ALL of: CONFIG_USERSPACE=y; exactly one of the PECI drivers enabled (CONFIG_PECI_NPCX, CONFIG_PECI_XEC, or CONFIG_PECI_ITE_IT8XXX2); and local code execution in a user-mode thread that has been granted the PECI device object via the standard device-granting mechanism. The concrete trigger is a peci_transfer() call whose embedded struct peci_buf members (tx_buffer/rx_buffer) carry caller-controlled buf pointers and len values that, pre-patch, were passed unchecked into the driver. Limiting factors that reduce realistic risk: the attack is local only (no network reachability), the attacker must already possess a granted PECI device handle (not default for arbitrary user threads), and the target build must enable USERSPACE together with a vulnerable PECI driver - platforms without PECI hardware/driver are unaffected.

All signals point to a genuine, high-integrity local privilege-escalation flaw rather than a mass-exploitable internet threat. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) is internally consistent with the description: exploitation is LOCAL (AV:L), of LOW complexity (AC:L - no race or special timing, just crafted pointers), and requires LOW privileges (PR:L) because the attacker must already run as a user-mode thread that has been granted the PECI device object. The C:H/I:H/A:H triad is well justified - the description gives an arbitrary kernel READ (confidentiality, disclosed to a PECI bus observer), an arbitrary kernel WRITE leading to supervisor code execution (integrity), and a trivially reachable supervisor fault (availability). No EPSS score, KEV listing, or SSVC decision data was supplied, and there is no indication of public exploit code, so exploitation-probability signals are ABSENT rather than low - read this as 'likelihood unknown,' not 'safe.' This is a real priority for anyone shipping Zephyr with CONFIG_USERSPACE and a PECI driver, since it defeats the userspace sandbox that is the entire security promise of CONFIG_USERSPACE; but it is NOT remotely wormable - the local-only vector and the prerequisite of already holding the PECI device object sharply bound the realistic attacker population. One conflict to flag explicitly: the 'RCE' tag implies remote code execution, yet the CVSS vector is AV:L and the description describes LOCAL code execution escalating to supervisor privilege - treat this as a local sandbox escape / privilege escalation, not network RCE.

A low-privileged user-mode Zephyr application that has legitimately been granted the PECI device object (the normal way CONFIG_USERSPACE exposes a device) invokes peci_transfer() with a crafted struct peci_msg whose rx_buffer.buf points at kernel memory and whose len is attacker-chosen. Because the pre-patch z_vrfy_peci_transfer() validated only the device handle and the outer struct, the driver dereferences those pointers in supervisor mode, yielding an arbitrary kernel write (hardware bytes written into kernel memory) and an arbitrary kernel read (kernel memory pushed onto the PECI/eSPI out-of-band bus). No public exploit identified at time of analysis, though the primitive is straightforward given the low attack complexity.