Description

The system-call verifier for i3c_do_ccc() in drivers/i3c/i3c_handlers.c validated the outer struct i3c_ccc_payload, the broadcast ccc.data buffer and the targets.payloads[] array, but did not validate the per-target data buffers those array elements point at. Each struct i3c_ccc_target_payload carries its own data pointer and data_len, and neither was passed through K_SYSCALL_MEMORY() before the payload was handed to z_impl_i3c_do_ccc() and on to the controller driver. The verifier also operated on the caller's live structure rather than a snapshot, so validated fields could be changed by a second user thread between the check and the driver's use — unlike the sibling z_vrfy_i3c_transfer(), which has always copied its message array first. The defect is only present in CONFIG_USERSPACE builds, where drivers/i3c/i3c_handlers.c is compiled. An unprivileged user-mode thread that has been granted access to the I3C controller device object — the ordinary way an application lets a user thread talk to I3C peripherals — can issue a direct CCC whose target payload data pointer names an arbitrary kernel address. Controller drivers dereference that pointer directly (for example drivers/i3c/i3c_mcux.c, drivers/i3c/i3c_cdns.c, drivers/i3c/i3c_stm32.c, drivers/i3c/i3c_npcx.c), using rnw to decide direction. A read CCC therefore causes the kernel-mode driver to write bus-received bytes into an attacker-chosen kernel address for an attacker-chosen length, and a write CCC transmits kernel memory out onto the I3C bus. The result is an out-of-bounds kernel write plus a kernel memory disclosure, i.e. escalation from a user-mode thread to supervisor privilege, defeating the isolation CONFIG_USERSPACE is meant to provide. The fix introduces copy_ccc_and_do(), which snapshots the payload, copies the target array into kernel memory with k_usermode_alloc_from_copy() (bounding num_targets to fewer than 32), validates each per-target buffer with K_SYSCALL_MEMORY() according to rnw, and copies the driver-written num_xfer and err fields back to the caller.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-05T09:17:13.077Z",
  "pubdate": "2026-10-05T09:17:13.077Z",
  "executiveSummary": "A critical vulnerability exists in the Zephyr RTOS I3C subsystem within the i3c_do_ccc() system call handler, specifically affecting CONFIG_USERSPACE builds.\nThe vulnerability is characterized by improper input validation and a time-of-check-to-time-of-use (TOCTOU) race condition, leading to unauthorized kernel memory access.\nAn unprivileged user-mode thread with access to an I3C controller can exploit this to achieve arbitrary kernel memory reads and writes.\nThe flaw allows escalation of privileges from a restricted user-mode context to full supervisor/kernel-level execution, effectively bypassing the isolation mechanisms provided by CONFIG_USERSPACE.\nSuccessful exploitation enables an attacker to leak sensitive kernel data or overwrite critical kernel structures, resulting in full system compromise.\nThe vulnerability impacts systems where I3C drivers are configured for user-mode access.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient validation of the 'struct i3c_ccc_target_payload' array passed to 'i3c_do_ccc()' in 'drivers/i3c/i3c_handlers.c'.\nWhile the verifier performed basic checks on the outer structure and the broadcast buffer, it failed to perform 'K_SYSCALL_MEMORY()' validation on the per-target data pointers and 'data_len' fields embedded within the 'targets.payloads[]' array.\nAdditionally, the verifier operated on the user-provided structure directly rather than creating a kernel-side snapshot. This introduced a TOCTOU (Time-of-Check-to-Time-of-Use) vulnerability where a secondary malicious thread could modify the payload fields after the initial validation but before the kernel driver consumed them.\nWhen an unprivileged user-mode thread invokes the system call, it provides a pointer to a 'struct i3c_ccc_target_payload'. Because the kernel driver dereferences the user-controlled 'data' pointer directly, an attacker can supply an arbitrary memory address.\nIn a read-mode CCC transaction, the controller driver writes incoming bus data into the attacker-supplied kernel address. This results in an out-of-bounds kernel memory write, allowing an attacker to corrupt kernel-mode data structures, overwrite function pointers, or modify security policy enforcement.\nIn a write-mode CCC transaction, the driver reads from the attacker-supplied kernel address and transmits the contents onto the I3C bus. This facilitates kernel memory disclosure, potentially leaking sensitive credentials, cryptographic keys, or kernel memory layout information to the user-mode attacker.\nThis vulnerability affects multiple I3C controller drivers, including 'drivers/i3c/i3c_mcux.c', 'drivers/i3c/i3c_cdns.c', 'drivers/i3c/i3c_stm32.c', and 'drivers/i3c/i3c_npcx.c', as these drivers lack sufficient validation before performing hardware-backed data transfers.\nThe attack flow proceeds as follows: 1) The attacker allocates a malicious payload structure in user memory; 2) The attacker invokes 'i3c_do_ccc()'; 3) Due to the lack of snapshotting and pointer validation, the kernel accepts the pointer; 4) The driver performs DMA or direct memory access using the attacker's pointer, either overwriting internal kernel state (for writes) or exposing memory (for reads)."
}