CVE-2026-43353

What it actually does

This is a local Linux kernel race condition in the MIPI I3C HCI driver DMA transfer dequeue path. When multiple I3C DMA transfers time out at about the same time, hci_dma_dequeue_xfer() can be entered concurrently without serialization. Competing executions may stop, process, and restart the DMA ring out of order, potentially corrupting driver state or causing unsafe handling of incomplete transfers. Because the flaw occurs in kernel context, successful exploitation could lead to denial of service through kernel crash or device lockup, and may potentially allow local privilege escalation or kernel memory corruption depending on hardware, driver configuration, and exploitability of the resulting race.

Why it matters to the business

Systems using affected Linux kernels with MIPI I3C HCI hardware or enabled driver support could be exposed to local attacks that destabilize the host or potentially grant elevated privileges to an already authenticated local user. Operational impact is most relevant for embedded Linux, mobile, IoT, industrial, and hardware-control systems where I3C-attached components are used. The current EPSS is low and there is no known KEV listing or public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, kernel flaws with local privilege escalation potential should still be remediated during normal kernel maintenance windows.

How an attack unfolds

An attacker first needs local code execution or an account on a system running an affected Linux kernel with the vulnerable MIPI I3C HCI driver reachable through configured hardware or device interfaces. The attacker then attempts to induce multiple I3C DMA transfer timeouts in close succession so that hci_dma_dequeue_xfer() is invoked concurrently. Because the vulnerable code path is not protected by a mutex, two or more executions can interfere while stopping and restarting the DMA ring and processing incomplete transfers. If the race is won, the result may be a kernel crash, device/driver hang, or potentially corruption of kernel driver state that could be shaped into privilege escalation on susceptible systems. No public exploit maturity or known threat actor exploitation is currently reported for this vulnerability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix adding serialization around hci_dma_dequeue_xfer(). Because no exact fixed package versions were provided, use the corrected kernel release or distribution advisory for the affected Linux distribution, appliance, or embedded vendor. If immediate patching is not possible, reduce exposure by disabling unused I3C/MIPI I3C HCI support, removing or blacklisting the relevant kernel module where operationally safe, limiting local shell access, restricting access to device nodes associated with I3C hardware, and applying least-privilege controls to services that run local code. For embedded or appliance environments, obtain firmware or BSP updates from the device vendor.

How to confirm the fix worked

Confirm the running kernel build includes the patch that serializes hci_dma_dequeue_xfer(), typically by checking the distribution kernel changelog, vendor advisory, package version, or source tree for the added mutex around the MIPI I3C HCI DMA dequeue path. Validate whether the vulnerable driver is present or loaded by reviewing kernel configuration and loaded modules for I3C/MIPI I3C HCI support. After patching, reboot into the updated kernel and verify with uname/package-manager output that the fixed kernel is active, not merely installed. Where feasible in a test environment, run I3C transfer timeout stress tests and confirm that concurrent timeout handling no longer causes kernel warnings, lockups, or crashes.

Typical attack path

1. Gain local access to the target system as an unprivileged user or through an already compromised process.
2. Confirm the system is running an affected Linux kernel with MIPI I3C HCI driver support and relevant I3C hardware exposed.
3. Trigger I3C DMA transfers that are likely to time out.
4. Cause multiple transfer timeouts to occur close together, producing concurrent calls into hci_dma_dequeue_xfer().
5. Exploit the unsynchronized stop/dequeue/restart sequence in the DMA ring handling path.
6. Use the resulting kernel instability or memory/state corruption to crash the system, disrupt device operation, or attempt local privilege escalation.

How to detect it

Detection is difficult because exploitation occurs as a kernel race and may leave only instability artifacts rather than a clear exploit signature. Review kernel logs, persistent journal entries, crash dumps, pstore/ramoops data, and hardware-driver telemetry for I3C or DMA timeout activity followed by kernel warnings, oopses, hung tasks, panics, or unexpected reboots. Correlate any such events with local user activity, newly executed binaries, scripts, container workloads, or repeated attempts to access I3C-related device interfaces. On systems with crash dump collection, inspect vmcore data for stack traces involving hci_dma_dequeue_xfer(), MIPI I3C HCI DMA ring handling, transfer timeout handling, or related I3C HCI functions. Because there are no known public exploit indicators or KEV-listed exploitation, prioritize behavioral evidence: repeated transfer timeouts, driver resets, kernel taint/oops records, and suspicious local execution immediately before a crash.

• hci_dma_dequeue_xfer
• mipi-i3c-hci
• i3c: mipi-i3c-hci
• I3C
• DMA ring
• dequeue_xfer
• transfer timeout
• timed out
• kernel oops
• kernel panic
• BUG: kernel NULL pointer dereference
• WARNING: CPU:
• INFO: task hung
• soft lockup
• hard lockup
• pstore
• ramoops

What your security team should do

• Inventory Linux systems, embedded devices, and appliances that use I3C/MIPI I3C HCI hardware or have the relevant kernel driver enabled.
• Prioritize patching systems where untrusted users, containers, workloads, or local services can execute code on the host.
• Track distribution and vendor advisories for exact fixed kernel package versions and deploy the corrected kernel or firmware when available.
• If patching is delayed, disable or blacklist unused I3C/MIPI I3C HCI driver support where this does not affect business-critical hardware functionality.
• Restrict local interactive access and access to hardware device nodes on systems that cannot be patched promptly.
• Monitor kernel logs for I3C, DMA, timeout, hung task, or kernel oops messages that may indicate attempted triggering or stability impact.
• Ensure EDR, auditd, and system logging preserve evidence of local command execution preceding any kernel crash or reboot.