CVE-2026-19676: PECI transfer syscall verifier does not validate embedded user buffer pointers, allowing arbitrary kernel memory read/write from user mode
The user-mode verifier for the pecitransfer() system call, zvrfypecitransfer() in drivers/peci/pecihandlers.c, checked only the device object permission and copied the caller-supplied struct pecimsg with kusermodefromcopy(). That copy validates the outer structure only; the buf pointers and len values inside the embedded struct pecibuf members txbuffer and rxbuffer remained fully caller-controlled and were passed unchecked to the driver.
Every in-tree PECI driver dereferences those pointers in supervisor mode: pecinpcxtransfer() in drivers/peci/pecinpcx.c and peciit8xxx2transfer() in drivers/peci/peciiteit8xxx2.c copy hardware bytes into rxbuffer.buf[i] and read command bytes out of txbuffer.buf[i], and pecixecread()/pecixecwrite() in drivers/peci/pecimchpxec.c do the same with no bound on rxbuffer.len at all. A user-mode thread that has been granted the PECI device object — the normal way an application exposes a device under CONFIGUSERSPACE — could therefore point rxbuffer.buf at kernel data structures and have the driver write hardware-supplied bytes there, or point txbuffer.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 CONFIGUSERSPACE=y, one of the PECI drivers enabled (CONFIGPECINPCX, CONFIGPECIXEC or CONFIGPECIITEIT8XXX2), and local code execution in a user-mode thread holding the PECI device.
The fix adds KSYSCALLMEMORYREAD() and KSYSCALLMEMORYWRITE() checks over the two embedded buffers, with a sizeaddoverflow() guard on the frame-check-sequence byte accounted for in the RX length.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to exploitation?
Exposure requires a user-mode thread that has been granted access to a PECI device object. This is relevant where an application exposes a PECI device under CONFIG_USERSPACE and an in-tree PECI driver is in use.
What does an attacker need to exploit this issue?
An attacker needs local user-mode code execution and permission to use the PECI device object. They can supply a PECI message whose embedded transmit or receive buffer pointers and lengths reference kernel memory.
What can exploitation accomplish?
A malicious receive buffer can cause hardware-supplied bytes to be written to kernel data structures, while a malicious transmit buffer can cause kernel memory contents to be sent over the PECI/eSPI path. The XEC implementation also has no bound on rx_buffer.len.
Which PECI driver implementations are implicated?
The described affected in-tree implementations are peci_npcx_transfer(), peci_it8xxx2_transfer(), peci_xec_read(), and peci_xec_write(). The first two read and write through caller-controlled embedded buffers, and the XEC functions do so without a receive-length bound.