CVE-2026-19185

Executive Summary

CVE-2026-19185 is a missing-validation and time-of-check/time-of-use (TOCTOU) defect in the Zephyr RTOS system-call verifier for i3c_do_ccc() in drivers/i3c/i3c_handlers.c. In CONFIG_USERSPACE builds, an unprivileged user-mode thread that has been granted access to an I3C controller device object can supply a target payload buffer pointer that names an arbitrary kernel address; the kernel-mode controller driver then dereferences it, enabling kernel memory read/write or disclosure. Impact is local privilege escalation and kernel memory corruption with CVSS 3.1 base score 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and CWE-822 categorization.

Technical Analysis

Zephyr's user-space subsystem enforces a syscall boundary: user threads call wrapper (verifier) functions prefixed z_vrfy_, which validate all caller-supplied pointers and lengths before forwarding to the implementation (z_impl_*). For I3C, the verifier z_vrfy_i3c_do_ccc() (referred to in the description as the system-call verifier for i3c_do_ccc()) was supposed to validate every memory region that the controller driver would subsequently dereference.

Per the NVD description, the verifier performed partial validation only:

1. It validated the outer struct i3c_ccc_payload.
2. It validated the broadcast ccc.data buffer.
3. It validated the targets.payloads[] array (the array of per-target payload structures).
4. It did not validate the per-target data buffers that those array elements point at.

Each struct i3c_ccc_target_payload carries its own data pointer and data_len. Neither field was passed through K_SYSCALL_MEMORY() before the payload was handed to z_impl_i3c_do_ccc() and on to the controller driver. K_SYSCALL_MEMORY() is the Zephyr macro family used to assert that a user-supplied memory region lies within the caller's permitted partition; skipping it means the kernel accepts an arbitrary pointer as a valid user buffer.

A second, independent defect compounds this: the verifier operated on the caller's live structure rather than a snapshot. Because the check and the driver's use are separated in time, a second user thread sharing the same structure can mutate the already-validated fields (including the data pointer and data_len) between validation and consumption — a classic TOCTOU race. The description contrasts this directly with the sibling z_vrfy_i3c_transfer(), which "has always copied its message array first" and is therefore immune to this class of racing.

The consequences of the missing check are described explicitly. Controller drivers dereference the unvalidated pointer directly. Named examples in the description include drivers/i3c/i3c_mcux.c, drivers/i3c/i3c_cdns.c, drivers/i3c/i3c_stm32.c, and drivers/i3c/i3c_npcx.c, which use the rnw (read/not-write) direction flag to decide transfer direction. Therefore:

• A read CCC causes the kernel-mode driver to write bus-received bytes into an attacker-chosen kernel address, for an attacker-chosen length — an arbitrary kernel write primitive.
• A write CCC transmits kernel memory contents out over the I3C bus — the description text is truncated at "transmits kernel me", but the direction and rnw semantics establish this as a kernel memory disclosure primitive.

The core attack surface is the syscall boundary itself. The description notes this defect "is only present in CONFIG_USERSPACE builds, where drivers/i3c/i3c_handlers.c is compiled." The premise for exploitation is that an unprivileged user-mode thread "has been granted access to the I3C controller device object — the ordinary way an application lets a user thread talk to I3C peripherals." No additional privilege is required beyond that normal device grant. Note that no vendor or product identification, affected version list, or OSV package mapping was supplied with this record, and no patch evidence exists from any tracked source.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template exists for CVE-2026-19185. The following chain is inferred strictly from the vulnerability class (CWE-822: Untrusted Pointer Dereference) and the mechanism described above — no implementation specifics beyond those in the description are assumed.

1. Reconnaissance / target identification. The attacker must already possess code execution as an unprivileged user-mode thread on a Zephyr device built with CONFIG_USERSPACE, running on a target whose I3C controller driver is one of the affected in-tree drivers. The thread must have been granted access to the I3C controller device object — the same grant an ordinary application uses to talk to I3C peripherals. There is no remote or network-reachable attack surface; host-side reconnaissance is limited to confirming that user-space I3C access is enabled and that the device tree exposes an I3C controller.

2. Triggering the specific flaw class. Rather than naming a valid buffer, the attacker populates a struct i3c_ccc_target_payload within the targets.payloads[] array with a data pointer that names an arbitrary kernel address and a data_len of the attacker's choosing. Because the verifier's K_SYSCALL_MEMORY() coverage stops at the targets.payloads[] array and does not descend into each element's data/data_len, the bogus pointer and length pass validation unchallenged. Alternatively, or in combination, the attacker uses a second user thread to rewrite data/data_len after validation but before the driver consumes the structure, exploiting the fact that the verifier checks the caller's live structure rather than a snapshot (the TOCTOU path that z_vrfy_i3c_transfer() avoids by copying its message array first).

3. Payload / execution method. The syscall proceeds into z_impl_i3c_do_ccc() and on to the controller driver. The driver dereferences the attacker-chosen pointer directly, using rnw to select direction. For a read CCC, the driver writes bus-received bytes into the attacker-chosen kernel address for the attacker-chosen length — an arbitrary kernel memory write. For a write CCC, the driver transmits kernel memory contents out over the I3C bus, producing a kernel memory disclosure.

4. Post-exploitation impact. With an arbitrary kernel write, an attacker can corrupt kernel data structures, control flow targets, or object metadata to escalate from an unprivileged user thread to kernel execution — the CVSS subscores reflect this (C:H/I:H/A:H). The disclosure primitive permits harvesting secrets or bypassing kernel address-space randomization by leaking memory contents. The result is full compromise of the device's confidentiality, integrity, and availability from a local, low-privilege starting point on an unpatched, user-space-enabled build.

Impact Assessment

Successful exploitation yields high confidentiality, integrity, and availability impact (CVSS 3.1: C:H/I:H/A:H) with a base score of 7.8. The scope is unchanged (S:U), meaning the impact is contained within the vulnerable Zephyr kernel/device security authority — the compromise does not spread into a separate security authority, but it does cross the critical user-to-kernel boundary.

Attack complexity is low (AC:L) and privileges required are low (PR:L), because the only precondition is the ordinary device-object grant that applications rely on to let user threads reach I3C peripherals. No user interaction (UI:N) and no network access (AV:L) are needed; the attacker's foothold is local code execution in an unprivileged user thread. The unvalidated data pointer is a direct, deterministic input to the driver, which keeps complexity low, while the TOCTOU variant of the flaw introduces a timing element that may raise practical reliability in some configurations but does not change the score.

Blast radius: any Zephyr deployment that builds with CONFIG_USERSPACE, compiles drivers/i3c/i3c_handlers.c, exposes an I3C controller, and grants a user-mode thread access to that controller is in scope. Embedded and IoT devices using I3C peripherals (sensors, NFC, power management, secure elements) on supported in-tree controllers are the primary population. Because the defect grants kernel read/write, a single compromised user-mode application can undermine the entire platform's security guarantees, including any isolation properties the CONFIG_USERSPACE boundary is meant to enforce. No CISA KEV listing and no confirmed in-the-wild exploitation are reported; EPSS has not been scored by FIRST.org, so no probabilistic exploitation metric is available.

Detection Guidance

Sigma Rule

title: Zephyr I3C CCC syscall with out-of-bounds target payload pointer (CVE-2026-19185)
id: 7c4b2a91-3f0d-4e8a-9b6c-1d2f5a7e8c40
status: experimental
description: Detects attempts to abuse the Zephyr i3c_do_ccc() verifier by supplying unvalidated per-target data pointers/lengths (CWE-822) in CONFIG_USERSPACE builds.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-19185
author: valtersit.com
date: 2026/01/01
logsource:
  product: linux
  service: auditd
detection:
  selection_syscall:
    type: 'SYSCALL'
    syscall: 'i3c_do_ccc'
  selection_memory:
    type: 'SECCOMP'
    syscall: 'i3c_do_ccc'
    errno: '-EINVAL'
  selection_fault:
    type: 'ANOM_ABEND'
    exe: '/dev/i3c*'
  condition: selection_syscall or selection_memory or selection_fault
falsepositives:
  - Legitimate I3C CCC traffic from trusted applications
  - Debug tooling exercising user-space I3C syscalls
level: high

YARA Rule

rule CVE_2026_19185_Zephyr_I3C_CCC_Verifier
{
    meta:
        description = "Detects Zephyr i3c_do_ccc verifier weakness and affected I3C build artifacts (CVE-2026-19185)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-19185"
        date = "2026-01-01"
        severity = "high"

    strings:
        $func = "i3c_do_ccc" ascii wide
        $vrfy = "z_vrfy_i3c_do_ccc" ascii wide
        $impl = "z_impl_i3c_do_ccc" ascii wide
        $usermem = "K_SYSCALL_MEMORY" ascii wide
        $sibling = "z_vrfy_i3c_transfer" ascii wide
        $src = "drivers/i3c/i3c_handlers.c" ascii wide

    condition:
        uint32(0) == 0x464c457f and
        any of ($func, $vrfy, $impl) and
        ($usermem or $sibling) and
        $src
}

Suricata IDS Rule

Note: CVE-2026-19185 has no network-reachable attack surface; this rule is directional-only and applies to host-attached lab environments where I3C activity is bridged to a monitored segment. If I3C is not exposed via a monitored transport, this signature will not fire.

alert ip any any -> any any (msg:"CVE-2026-19185 Zephyr I3C do_ccc abnormal target payload transfer"; flow:to_server; content:"i3c_do_ccc"; nocase; sid:202619185; rev:1; classtype:attempted-user; reference:cve,CVE-2026-19185; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

Elastic Detection

process where event.action == "start" and
  process.args : "*i3c_do_ccc*" and
  process.parent.name : ("userapp" or "test_*" or "ztest") and
  process.executable : ("/dev/i3c*" or "/tmp/*")

Splunk SPL Query

index=embedded OR index=linux_audit (syscall="i3c_do_ccc" OR message="*i3c_handlers.c*" OR tag="i3c")
| stats count values(errno) as errnos values(pid) as pids by host, syscall, exe
| where errno="-EINVAL" OR count > 100
| table host, syscall, exe, count, errnos, pids
| sort - count

Wazuh OSSEC Rule

<group name="zephyr,i3c,cve-2026-19185">
  <rule id="202691" level="10">
    <decoded_as>json</decoded_as>
    <field name="syscall">i3c_do_ccc</field>
    <description>CVE-2026-19185: Zephyr I3C do_ccc syscall observed - possible unvalidated target payload pointer abuse</description>
    <mitre>
      <id>T1068</id>
    </mitre>
    <group>privilege_escalation,</group>
  </rule>
  <rule id="202692" level="12">
    <if_sid>202691</if_sid>
    <field name="errno">-EINVAL</field>
    <description>CVE-2026-19185: Zephyr I3C do_ccc verifier rejection - probe or malformed CCC payload detected</description>
    <group>privilege_escalation,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source, no vendor fix is available, and no affected-version list has been published. The following guidance is derived from the described defect and standard Zephyr hardening practice; verify any future fix against upstream Zephyr before relying on it.

1. Immediate mitigations

   • Disable CONFIG_USERSPACE on builds where user-space isolation is not strictly required. The description states the defect "is only present in CONFIG_USERSPACE builds, where drivers/i3c/i3c_handlers.c is compiled"; removing that configuration removes the vulnerable code path entirely.
   • Where user-space builds are mandatory, revoke or avoid granting unprivileged user threads access to the I3C controller device object unless absolutely necessary. The exploit precondition is exactly this ordinary device grant.
   • Restrict the I3C subsystem to kernel-mode threads only, eliminating the syscall-boundary attack surface for this code path.
   • Ensure that no second user thread can concurrently mutate I3C payload structures passed to i3c_do_ccc(), as the TOCTOU variant depends on shared, mutable state between check and use.

2. Patch / upgrade steps

   • No vendor fix or reference commit is available as of this record. Monitor upstream Zephyr security advisories and the drivers/i3c/i3c_handlers.c file for a corrective commit.
   • A correct fix must do two things mirroring the description: (a) add K_SYSCALL_MEMORY() coverage for each struct i3c_ccc_target_payload's data pointer and data_len before handing the payload to z_impl_i3c_do_ccc(), and (b) validate a snapshot of the caller's structure rather than the live one, following the pattern already used by z_vrfy_i3c_transfer(), which copies its message array first.
   • Until such a fix ships, treat all user-mode I3C CCC calls as untrusted; do not assume the syscall filter enforces memory safety.

3. Long-term hardening

   • Adopt a convention that every verifier must deep-validate all pointers reachable from a syscall argument, not only top-level buffers and arrays — treat nested data/data_len pairs as mandatory K_SYSCALL_MEMORY() targets.
   • Standardize snapshot-and-validate semantics across all z_vrfy_* functions so that no verifier operates on caller-owned live memory, eliminating TOCTOU at the syscall boundary as a class.
   • Add automated checks (static analysis or unit tests) that enumerate pointer-bearing structs in syscall arguments and fail the build if any member lacks validation coverage.
   • Review all I3C and comparable driver handlers (i3c_mcux.c, i3c_cdns.c, i3c_stm32.c, i3c_npcx.c) for direct dereference of user-supplied pointers and reinforce them with kernel-side bounds checking as defense in depth.
   • Minimize the set of user-mode threads granted access to I3C controller objects and audit those grants regularly.

References

• NVD — CVE-2026-19185: https://nvd.nist.gov/vuln/detail/CVE-2026-19185
• Zephyr Project — Security advisories and kernel user-space / syscall verification documentation: https://docs.zephyrproject.org/
• Zephyr upstream source — drivers/i3c/i3c_handlers.c (verifier z_vrfy_i3c_do_ccc() and z_vrfy_i3c_transfer()): https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/i3c/i3c_handlers.c
• CWE-822 — Untrusted Pointer Dereference: https://cwe.mitre.org/data/definitions/822.html
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-19185 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public proof-of-concept, exploit code, or Nuclei template is known for this CVE, and no threat-attribution or in-the-wild exploitation evidence has been reported. EPSS has not been scored by FIRST.org at the time of writing. Exploitation is constrained to local attackers holding an unprivileged user-mode thread with I3C controller device access on a CONFIG_USERSPACE build.