CVE-2026-19737

Executive Summary

CVE-2026-19737 is a NULL pointer dereference vulnerability in the Zephyr RTOS i2s_esp32 driver, specifically within i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c. On ESP32 device instances that wire only a single I2S direction (RX or TX), the device instantiation macro I2S_ESP32_STREAM_INIT() sets the unused direction's stream pointers (.conf and .data) to NULL, and the trigger-check logic dereferences the corresponding dev_cfg->rx.data->configured or dev_cfg->tx.data->configured field without a prior NULL check. A user-mode Zephyr thread granted access to the I2S device can issue a single i2s_trigger() syscall specifying the unwired direction, causing a load from address 0 in kernel mode. The CVSS score is 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a local, low-privilege availability impact with no confidentiality or integrity loss. Affected platforms are constrained to Zephyr v4.4.0+ builds on Espressif RISC-V SoCs (e.g., ESP32-C6 HPCORE) with CONFIG_USERSPACE and CONFIG_RISCV_PMP enabled.

Technical Analysis

The i2s_esp32_trigger_check() function in drivers/i2s/i2s_esp32.c performs validation of the requested direction argument passed to the I2S trigger API. The validation logic covers only the I2S_DIR_BOTH case properly. When the caller specifies I2S_DIR_RX or I2S_DIR_TX, the function branches into code that reads dev_cfg->rx.data->configured or dev_cfg->tx.data->configured respectively, without first confirming that the relevant stream pointer (rx.data or tx.data) is non-NULL.

The root cause is a structural mismatch in device instantiation. The I2S_ESP32_STREAM_INIT() macro initializes both .conf and .data fields to NULL for any direction the devicetree does not describe. This is the normal and expected shape for many real-world I2S usages: an audio output device typically wires only the TX direction, and a worldsemi,ws2812-i2s LED strip similarly uses only one direction (TX). For such a single-direction instance, the opposite direction's stream pointers are NULL by design. When a caller invokes the trigger API naming that unwired direction, the driver's direction-specific branch performs a load through the NULL pointer.

The attack surface is exposed through i2s_trigger(), which is a Zephyr syscall. The syscall verifier z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only two things: the device object reference and the presence of the trigger API pointer. Critically, the dir argument is passed to the driver unvalidated. This means a user-mode thread that has been granted the I2S device can supply an arbitrary direction value, including the unwired direction, and the kernel-mode driver will process it.

The exploitation preconditions are specific and narrow. CONFIG_USERSPACE must be enabled at build time to allow a user-mode caller to reach the syscall verifier. Among Espressif parts carrying this driver, in-tree userspace support is available only on RISC-V SoCs that enable CONFIG_RISCV_PMP. Zephyr v4.4.0 is identified as the first release where this combination is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when it is not built for MCUboot. The ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCV_PMP by default. Espressif Xtensa targets do not support Zephyr userspace at all. In a non-userspace build, the report data indicates the bad behavior is present but the privilege boundary that makes it a memory-safety issue for a constrained user-mode caller does not apply in the same way. The NVD description is truncated at "in a non-userspace build the bad", leaving the precise non-userspace consequence unspecified in the provided data. What is established is a kernel-mode NULL pointer load (CWE-476) exercised via a syscall with an unvalidated direction argument.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template is available for CVE-2026-19737. The attack chain below is inferred strictly from the vulnerability class and the mechanics documented in the NVD description; no fabricated function names, endpoints, or parameters beyond those explicitly named in the description are used.

1. Target identification / reconnaissance. An attacker must first obtain code execution as a user-mode Zephyr thread on a device whose firmware was built with CONFIG_USERSPACE enabled, running on an affected Espressif RISC-V SoC (for example, ESP32-C6 HPCORE with CONFIG_RISCV_PMP selected, or an ESP32-C5 configuration where CONFIG_RISCV_PMP has been explicitly enabled). The attacker must also determine that the target firmware wires only one I2S direction (TX-only audio output or a worldsemi,ws2812-i2s LED strip are the normal single-direction shapes), meaning the opposite direction's rx.data / tx.data pointers are NULL.

2. Trigger of the flaw class. The attacker, running as a user-mode thread that has already been granted access to the I2S device object, issues a single i2s_trigger() syscall naming the unwired direction (I2S_DIR_RX on a TX-only instance, or I2S_DIR_TX on an RX-only instance). The syscall verifier z_vrfy_i2s_trigger() validates the device object and the trigger API pointer but does not validate the dir argument, so the request proceeds into the driver. Inside i2s_esp32_trigger_check(), the unvalidated direction selects the branch that reads the NULL stream pointer's configured field, producing a load from address 0 in kernel mode.

3. Payload / execution method. No payload is required. The vulnerability is a NULL pointer dereference (CWE-476); a single syscall with the wrong direction argument is sufficient to drive the kernel-mode load. There is no evidence in the provided data of an exploitable write primitive, controlled offset, or memory corruption escalation path — the documented consequence is a load from address 0.

4. Post-exploitation impact. The principal demonstrated impact is a kernel-mode fault. On an RTOS without robust fault containment, a fault in kernel context typically results in a system crash, hang, or reset — a denial-of-service condition for the device and anything depending on it. The CVSS vector (C:N/I:N/A:H) confirms that only availability is impacted, with high severity, and no confidentiality or integrity loss. No privilege-escalation outcome beyond the kernel fault is supported by the available data.

Impact Assessment

The CVSS 3.1 base score is 5.5 (Medium), with vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. The subscore profile is:

• Attack Vector (Local): The attacker must already run code on the device as a user-mode thread — network reachability is not implied.
• Attack Complexity (Low): A single syscall naming the unwired direction triggers the NULL dereference; no race condition or special environment is described.
• Privileges Required (Low): The attacker needs a user-mode thread with a grant on the I2S device, matching Zephyr's userspace permission model.
• User Interaction (None): No victim action is needed beyond the attacker's own syscall.
• Scope (Unchanged): The fault remains within the vulnerable component's security authority.
• Confidentiality/Integrity (None): The documented effect is a load from address 0, not data disclosure or modification.
• Availability (High): A kernel-mode fault can crash, hang, or reset the device.

Business impact is concentrated on device availability and operational continuity for products embedding affected Zephyr builds. Embedded systems such as audio output devices and worldsemi,ws2812-i2s-based LED controllers are plausible deployment shapes given the TX-only configuration described as the "normal shape." The blast radius is bounded by three hard preconditions: (1) an Espressif RISC-V target with CONFIG_USERSPACE and CONFIG_RISCV_PMP enabled (ESP32-C6 HPCORE not built for MCUboot, or ESP32-C5 with RISCV_PMP explicitly enabled), (2) an I2S instance wiring only one direction, and (3) an attacker capable of executing a user-mode thread holding an I2S device grant. Products built without userspace, or on Espressif Xtensa targets (which do not support Zephyr userspace), fall outside the primary exploitable scope described. There is no CISA KEV listing and no evidence of active exploitation in the wild at the time of this report.

Detection Guidance

Detection for this class of flaw is primarily host- and firmware-side, since exploitation is a local syscall rather than a network-visible event. The rules below are provided as starting points and should be tuned to the specific firmware build, RTOS logging configuration, and deployment. Given the absence of named network indicators, network-layer rules target generic crash/reset telemetry rather than the syscall itself.

Sigma Rule

title: Zephyr ESP32 I2S NULL Pointer Dereference via Invalid Direction Argument
id: 8f3c9a12-6c2e-4d1a-9b7e-2f5a4c1d0e77
status: experimental
description: Detects kernel-mode faults consistent with CVE-2026-19737, where i2s_trigger() is called with an unwired I2S direction on Zephyr ESP32 devices, causing a load from address 0 in i2s_esp32_trigger_check().
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-19737
author: valtersit.com
date: 2026/01/01
logsource:
  category: application
  product: zephyr
detection:
  selection_fault:
    LogSource: 'zephyr'
    Message|contains:
      - 'i2s_esp32_trigger_check'
      - 'i2s_handlers'
      - 'i2s_trigger'
  selection_faulttype:
    Message|contains:
      - 'NULL pointer'
      - 'load from address 0'
      - 'Fatal exception'
      - 'Kernel panic'
      - 'NULL_POINTER'
      - 'K_ERR_CPU_EXCEPTION'
  selection_direction:
    Message|contains:
      - 'I2S_DIR_RX'
      - 'I2S_DIR_TX'
  condition: selection_fault and (selection_faulttype or selection_direction)
falsepositives:
  - Legitimate driver error paths that log I2S direction validation
  - Development/debug builds with verbose I2S logging
level: high
tags:
  - attack.t1068
  - cwe.476

YARA Rule

rule CVE_2026_19737_Zephyr_I2S_Null_Deref
{
    meta:
        description = "Detects Zephyr i2s_esp32 driver code strings associated with CVE-2026-19737 NULL pointer dereference in i2s_esp32_trigger_check()"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-19737"
        date = "2026-01-01"
        cve = "CVE-2026-19737"

    strings:
        $drv = "drivers/i2s/i2s_esp32.c" ascii
        $fn1 = "i2s_esp32_trigger_check" ascii
        $fn2 = "z_vrfy_i2s_trigger" ascii
        $fn3 = "i2s_handlers.c" ascii
        $macro = "I2S_ESP32_STREAM_INIT" ascii
        $dir1 = "I2S_DIR_BOTH" ascii
        $dir2 = "I2S_DIR_RX" ascii
        $dir3 = "I2S_DIR_TX" ascii
        $field1 = "dev_cfg->rx.data->configured" ascii
        $field2 = "dev_cfg->tx.data->configured" ascii
        $ws = "worldsemi,ws2812-i2s" ascii
        $pmp = "RISCV_PMP" ascii

    condition:
        (uint32(0) == 0x464C457F or true) and
        (
            ($fn1 and ($dir2 or $dir3)) or
            ($fn2 and $macro) or
            ($field1 or $field2) or
            ($drv and $fn1) or
            ($ws and $pmp and $fn1)
        )
}

Suricata IDS Rule

alert udp any any -> any any (msg:"CVE-2026-19737 Zephyr ESP32 I2S NULL Pointer Dereference - Post-Crash Device Fault Telemetry"; flow:to_server; content:"i2s_esp32_trigger_check"; nocase; content:"NULL"; nocase; distance:0; within:512; classtype:attempted-dos; reference:cve,2026-19737; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-19737; metadata:created_at 2026_01_01, updated_at 2026_01_01, mitre_tactic T1068; sid:2026197370; rev:1;)

Note: CVE-2026-19737 is a local syscall-triggered kernel fault and does not generate a canonical network signature. The rule above is a best-effort match against device log/fault telemetry transported over the network (for example, syslog or a debug channel) and should be tuned. No network-level signature can reliably detect the syscall itself.

Elastic Detection

process where event.type in ("start", "change") and
  process.name : ("zephyr", "west", "minicom", "picocom", "screen") and
  process.command_line : "*i2s_trigger*"

event.category: "process" and
  (process.command_line : "*i2s_esp32_trigger_check*" or
   process.command_line : "*z_vrfy_i2s_trigger*" or
   process.command_line : "*I2S_DIR_RX*" or
   process.command_line : "*I2S_DIR_TX*")

Splunk SPL Query

index=embedded OR index=iot
(source="zephyr*" OR host="*esp32*")
("i2s_esp32_trigger_check" OR "z_vrfy_i2s_trigger" OR "i2s_handlers.c")
("NULL pointer" OR "load from address 0" OR "Fatal exception" OR "Kernel panic" OR "K_ERR_CPU_EXCEPTION")
| stats count min(_time) as first_seen max(_time) as last_seen by host, sourcetype, message
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="zephyr,cve-2026-19737,">
  <rule id="202619737" level="12">
    <decoded_as>json</decoded_as>
    <field name="message">i2s_esp32_trigger_check|z_vrfy_i2s_trigger|i2s_handlers\.c</field>
    <description>CVE-2026-19737: Potential Zephyr ESP32 I2S NULL pointer dereference via i2s_trigger() direction argument</description>
    <options>no_full_log</options>
    <mitre>
      <id>T1068</id>
    </mitre>
    <group>cve_2026_19737,null_pointer,</group>
  </rule>

  <rule id="202619738" level="13">
    <decoded_as>json</decoded_as>
    <field name="message">NULL pointer|load from address 0|K_ERR_CPU_EXCEPTION|Kernel panic</field>
    <description>CVE-2026-19737: Zephyr ESP32 kernel-mode fault consistent with I2S NULL pointer dereference</description>
    <options>no_full_log</options>
    <mitre>
      <id>T1068</id>
    </mitre>
    <group>cve_2026_19737,kernel_fault,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix and no workarounds are documented in the available intelligence. The guidance below is derived from the vulnerability mechanics and Zephyr configuration model; it does not constitute a vendor-endorsed remedy.

1. Immediate mitigations

• Audit Zephyr deployments on Espressif RISC-V SoCs (ESP32-C6 HPCORE, ESP32-C5) that build with CONFIG_USERSPACE enabled and an affected I2S instance. Prioritize devices whose devicetree describes only a single I2S direction (TX-only audio output; worldsemi,ws2812-i2s LED strips), which is the configuration shape that leaves the opposite stream pointers NULL.
• Where userspace is not a functional requirement, disable CONFIG_USERSPACE in affected builds. The preconditions for the user-mode syscall path described in the CVE require a user-mode caller; removing userspace removes that caller class.
• On affected RISC-V targets, review whether CONFIG_RISCV_PMP is required. The CVE notes that ESP32-C5 in v4.4.x does not select RISCV_PMP by default, and that ESP32-C6 HPCORE selects it only when not built for MCUboot. Avoiding the userspace/PMP combination where feasible eliminates the described in-tree exploitable path.
• Constrain which user-mode threads are granted the I2S device object. Restricting device grants reduces the set of threads able to reach i2s_trigger().

2. Patch / upgrade steps

• No fixed Zephyr release is identified in the available data. Monitor the Zephyr project security advisories and the upstream drivers/i2s/i2s_esp32.c / drivers/i2s/i2s_handlers.c sources for a fix that adds a NULL check on the direction-specific stream pointers in i2s_esp32_trigger_check() and/or validates the dir argument in z_vrfy_i2s_trigger().
• Track Zephyr release notes for versions after v4.4.0 for a remediation reference to CVE-2026-19737. Do not assume any specific release is fixed until confirmed by the vendor.
• If maintaining a downstream fork, consider applying a local defensive change that rejects I2S_DIR_RX/I2S_DIR_TX when the corresponding rx.data/tx.data stream pointer is NULL, and that validates dir in the syscall verifier, until an upstream fix is available.

3. Long-term hardening

• Adopt syscall-verifier hardening practices: ensure all syscall arguments, not only object handles and API pointers, are validated in z_vrfy_* handlers before entering driver code.
• Establish CI checks that exercise driver entry points with every enumerated direction value against single-direction devicetree instances, to catch unchecked stream-pointer branches.
• Favor build configurations that reduce kernel-mode attack surface (careful review of CONFIG_USERSPACE grants and RISC-V PMP enablement) when the application does not require the corresponding isolation features.
• Maintain an SBOM and firmware version inventory to rapidly identify devices running affected Zephyr v4.4.0+ configurations.

References

• NVD — CVE-2026-19737: https://nvd.nist.gov/vuln/detail/CVE-2026-19737
• MITRE CWE-476 — NULL Pointer Dereference: https://cwe.mitre.org/data/definitions/476.html
• Zephyr Project Security Advisories: https://github.com/zephyrproject-rtos/zephyr/security/advisories
• Zephyr Project Documentation — Userspace and Syscalls: https://docs.zephyrproject.org/latest/kernel/usermode/index.html
• FIRST EPSS (score not yet assigned for this CVE): https://www.first.org/epss/

Note on exploit evidence: CVE-2026-19737 is not listed in CISA KEV, and no public proof-of-concept, exploit code, Nuclei template, or in-the-wild campaign is identified in the available intelligence. No EPSS score has been assigned by FIRST.org at the time of this report. No patch, vendor fix, or workaround is currently documented.