---
id: "CVE-2026-19676"
kind: "vulnerability"
aliases: ["CVE-2026-19676"]
title: "Zephyr: PECI syscall lets user threads write kernel memory"
severity: "high"
cvss: 7.8
epss: 0.00114
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded", "peci", "runtime", "userspace", "zephyr"]
not_affected_if: ["no-peci-driver", "no-user-threads-with-peci-access", "no-userspace"]
published_at: "2026-10-21T19:17:02+00:00"
first_seen_at: "2026-10-23T21:57:29+00:00"
updated_at: "2026-10-25T03:08:16+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19676", "first_seen_at": "2026-10-23T21:57:29+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-19676", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Zephyr: PECI syscall lets user threads write kernel memory

The PECI transfer system call in Zephyr does not check the buffer pointers and lengths inside its message struct, so a user-mode thread holding the PECI device can point them at kernel memory. An attacker can write hardware-supplied bytes into kernel memory for code execution at supervisor privilege, or read kernel data out over the PECI bus.

_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 enables one of `CONFIG_PECI_NPCX`, `CONFIG_PECI_XEC` or `CONFIG_PECI_ITE_IT8XXX2`
- Check the Zephyr version in the tree with `git describe --tags` and compare it with the fixed release in the advisory (unknown in sources)

## Fix

- Update Zephyr to a release containing the fix that adds `K_SYSCALL_MEMORY_READ()` and `K_SYSCALL_MEMORY_WRITE()` checks in `drivers/peci/peci_handlers.c` (fixed version: unknown in sources)
- Until updated, avoid granting user threads the PECI device object or disable `CONFIG_USERSPACE` for affected builds

## Timeline

- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-19676
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-19676

## From the sources

The user-mode verifier for the peci_transfer() system call, z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, checked only the device object permission and copied the caller-supplied struct peci_msg with k_usermode_from_copy(). That copy validates the outer structure only; the buf pointers and len values inside the embedded struct peci_buf members tx_buffer and rx_buffer remained fully caller-controlled and were passed unchecked to the driver.

Every in-tree PECI driver dereferences those pointers in supervisor mode: peci_npcx_transfer() in drivers/peci/peci_npcx.c and peci_it8xxx2_transfer() in drivers/peci/peci_ite_it8xxx2.c copy hardware bytes into rx_buffer.buf[i] and read command bytes out of tx_buffer.buf[i], and peci_xec_read()/peci_xec_write() in drivers/peci/peci_mchp_xec.c do the same with no bound on rx_buffer.len at all. A user-mode thread that has been granted the PECI device object — the normal way an application exposes a device under CONFIG_USERSPACE — could therefore point rx_buffer.buf at kernel data structures and have the driver write hardware-supplied bytes there, or point tx_buffer.buf at kernel memory and have its contents pushed onto the PECI/eSPI out-of-band bus.

The impact is a full user-mode-to-kernel escape: an arbitrary kernel write primitive (integrity and, through it, code execution at supervisor privilege), an arbitrary kernel read disclosed to a PECI bus observer, and a trivially reachable supervisor-mode fault if an unmapped address is supplied. Exploitation requires CONFIG_USERSPACE=y, 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 holding the PECI device.

The fix adds K_SYSCALL_MEMORY_READ() and K_SYSCALL_MEMORY_WRITE() checks over the two embedded buffers, with a size_add_overflow() guard on the frame-check-sequence byte accounted for in the RX length.

---

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