{"id":32746,"date":"2026-10-05T20:30:53","date_gmt":"2026-10-05T12:30:53","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-19185"},"modified":"2026-10-05T20:30:53","modified_gmt":"2026-10-05T12:30:53","slug":"cve-2026-19185","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-19185","title":{"rendered":"CVE-2026-19185 [HIGH] &#8211; The system-call verifier for i3c_do_ccc() in drivers\/i3c\/i3c_handlers.c validated the oute"},"content":{"rendered":"<p>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&#8217;s live structure rather than a snapshot, so validated fields could be changed by a second user thread between the check and the driver&#8217;s use \u2014 unlike the sibling z_vrfy_i3c_transfer(), which has always copied its message array first.<\/p>\n<p>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 \u2014 the ordinary way an application lets a user thread talk to I3C peripherals \u2014 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.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-32746","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/32746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=32746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=32746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=32746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}