CVE-2026-17052: Missing user-pointer validation in tgpio_pin_read_ts_ec syscall handler allows arbitrary supervisor-memory write from userspace
The Time-aware GPIO syscall verification handler zvrfytgpiopinreadtsec() in drivers/timeawaregpio/timeawaregpiohandlers.c validated only the port device object and passed the caller-supplied timestamp and eventcount output pointers to the driver without a KSYSCALLMEMORYWRITE() check. The other handlers in the same file (zvrfytgpioportgettime(), zvrfytgpioportgetcyclespersecond()) already performed that check, so the omission left one syscall unguarded.
tgpiopinreadtsec() is declared syscall, so with CONFIGUSERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpiointelreadtsec() in drivers/timeawaregpio/timeawaregpiointel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and eventcount = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller.
The result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel data structures this way can escalate the calling thread to supervisor privilege or crash the system; the device-object permission required is a narrow capability that is not intended to confer any kernel-memory access. The fix adds the two missing KSYSCALLMEMORYWRITE() validations before the driver call.
Exposure is narrow in practice. Only builds with CONFIGUSERSPACE=y and CONFIGTIMEAWAREGPIO=y compile the affected file, and from v3.6.0 onward the file additionally referenced a relocated header (<zephyr/syscallhandler.h>) and removed ZSYSCALL macros, so such a configuration failed to build until those were repaired after v4.4.0. Downstream trees that locally corrected that breakage, and v3.5.0 builds where it did not exist, are the exposed population.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
The issue is reachable only when CONFIG_USERSPACE is enabled and an unprivileged user-mode thread has been granted access to a TGPIO device object. Systems without user-mode syscall access or without such device access are not described as exploitable.
What does an attacker need to exploit this issue?
An attacker needs local code execution as an unprivileged user-mode thread, access to the TGPIO device object, and the ability to invoke the tgpio_pin_read_ts_ec() syscall. No user interaction is required.
What can exploitation achieve?
The caller can cause two 8-byte supervisor-mode writes to attacker-chosen addresses. The values written are hardware time-capture and event-counter register contents, and corrupting kernel memory can affect confidentiality, integrity, and availability.