Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-14367

CVE-2026-14367: I3C IBI Subsystem Race Condition DoS

CVE-2026-14367 is a race condition flaw in the I3C IBI subsystem that enables denial of service attacks through unsynchronized list operations. This post explains its technical details, impact, and mitigation steps.

Published:

CVE-2026-14367 Overview

CVE-2026-14367 is a race condition [CWE-362] in the Zephyr RTOS I3C In-Band Interrupt (IBI) subsystem. The flaw resides in drivers/i3c/i3c_ibi_workq.c, where a free-list of work nodes is accessed without synchronization. Allocation helpers call sys_slist_get() from Interrupt Service Routine (ISR) context, while the workqueue handler returns nodes with sys_slist_append() from a thread context. Neither operation is atomic or interrupt-safe. An attacker with control of an I3C peripheral on the chip-to-chip bus can trigger colliding accesses, corrupting the list linkage.

Critical Impact

Successful exploitation causes denial of service through crashes or hangs, with limited potential for out-of-bounds memory writes when list corruption yields a garbage pointer.

Affected Products

  • Zephyr RTOS I3C IBI subsystem (drivers/i3c/i3c_ibi_workq.c)
  • Builds enabling the I3C IBI workqueue feature
  • Configurations using CONFIG_SMP are additionally exposed to truly parallel access

Discovery Timeline

  • 2026-08-31 - CVE-2026-14367 published to NVD
  • 2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-14367

Vulnerability Analysis

The I3C IBI subsystem manages inbound interrupt events from target devices through statically-allocated work nodes. These nodes are drawn from a shared free-list, i3c_ibi_work_nodes_free, implemented as a plain sys_slist_t. The allocation helpers i3c_ibi_work_enqueue, i3c_ibi_work_enqueue_target_irq, i3c_ibi_work_enqueue_hotjoin, i3c_ibi_work_enqueue_controller_request, and i3c_ibi_work_enqueue_cb call sys_slist_get() directly from ISR context. The handler i3c_ibi_work_handler() returns nodes with sys_slist_append() from the workqueue thread. Neither path holds a lock.

When an IBI interrupt fires during a mid-append operation, the shared list races. The corruption produces three failure modes. The same node may be handed to two consumers. A node may be lost from the free-list entirely. The head or tail pointers may be left inconsistent, causing sys_slist_get() to return a stale or garbage pointer.

Root Cause

The root cause is missing synchronization on a data structure shared between ISR and thread contexts. sys_slist_get() and sys_slist_append() provide no atomicity guarantees. Under CONFIG_SMP, concurrent CPU access compounds the exposure.

Attack Vector

Exploitation requires physical access to the I3C bus. I3C supports hot-joining devices, so an attacker-controlled peripheral can issue high-frequency IBIs, hot-join requests, or controller-role requests timed to collide with the free operation. A double-hand-out drives a subsequent memcpy(ibi_node, ibi_work, sizeof(*ibi_node)) to overwrite an in-flight node. A garbage pointer converts the same memcpy into an out-of-bounds write. The realistic outcome is a crash or hang; controlled memory corruption is difficult.

c
 static sys_slist_t i3c_ibi_work_nodes_free;
 
+/* Spinlock protecting i3c_ibi_work_nodes_free list access from ISR and thread contexts */
+static struct k_spinlock ibi_work_lock;
+
 static inline int ibi_work_submit(struct i3c_ibi_work *ibi_node)
 {
 	return k_work_submit_to_queue(&i3c_ibi_work_q, &ibi_node->work);
 }
 
+static struct i3c_ibi_work *ibi_work_alloc(void)
+{
+	k_spinlock_key_t key = k_spin_lock(&ibi_work_lock);
+	sys_snode_t *node = sys_slist_get(&i3c_ibi_work_nodes_free);
+
+	k_spin_unlock(&ibi_work_lock, key);
+
+	return (struct i3c_ibi_work *)node;
+}
+
+static void ibi_work_free(struct i3c_ibi_work *ibi_node)
+{
+	k_spinlock_key_t key = k_spin_lock(&ibi_work_lock);
+
+	sys_slist_append(&i3c_ibi_work_nodes_free, (sys_snode_t *)ibi_node);
+	k_spin_unlock(&ibi_work_lock, key);
+}
+
 int i3c_ibi_work_enqueue(struct i3c_ibi_work *ibi_work)

Source: Zephyr commit e87e7e2ac7c5. The patch introduces ibi_work_alloc() and ibi_work_free() helpers guarded by the new k_spinlock ibi_work_lock, closing the race across ISR and thread contexts.

Detection Methods for CVE-2026-14367

Indicators of Compromise

  • Unexplained kernel faults or watchdog resets originating in i3c_ibi_work_handler() or nearby I3C driver frames.
  • Log entries showing I3C IBI event storms, repeated hot-join attempts, or controller-role requests from a single target device.
  • Duplicate delivery of IBI payloads to consumers or lost IBI events under load.

Detection Strategies

  • Instrument the I3C driver with debug assertions that validate free-list head and tail consistency after every allocation and release.
  • Fuzz the IBI path with a controlled I3C target generating high-frequency interrupts to reproduce the corruption.
  • Review firmware crash dumps for stack traces implicating sys_slist_get() or sys_slist_append() under I3C call paths.

Monitoring Recommendations

  • Track I3C bus telemetry for anomalous IBI, hot-join, and controller-role request rates from individual targets.
  • Correlate device resets and watchdog events with I3C traffic bursts on the same board.
  • Maintain firmware version inventory to flag devices running pre-patch Zephyr builds with I3C IBI enabled.

How to Mitigate CVE-2026-14367

Immediate Actions Required

  • Apply the upstream Zephyr patch that introduces ibi_work_alloc() and ibi_work_free() guarded by ibi_work_lock.
  • Rebuild and reflash affected firmware images across all boards using the I3C IBI subsystem.
  • Audit boards for untrusted I3C peripherals and remove or isolate devices that are not required.

Patch Information

The fix is available in Zephyr commit e87e7e2ac7c5ded0af3fb5934518cc5688e458cc and tracked under GHSA-gfj5-gcxv-9jqm. The patch wraps every sys_slist_get() and sys_slist_append() call on i3c_ibi_work_nodes_free with a k_spinlock, serializing access across ISR and thread contexts including CONFIG_SMP builds.

Workarounds

  • Disable the I3C IBI subsystem in Kconfig for builds that do not require in-band interrupt handling.
  • Restrict which target devices can hot-join the I3C bus at the hardware or firmware policy layer.
  • Where possible, enclose I3C peripherals in a physically protected boundary to eliminate untrusted bus participants.
bash
# Rebuild Zephyr with the patched revision
git fetch origin
git checkout e87e7e2ac7c5ded0af3fb5934518cc5688e458cc -- drivers/i3c/i3c_ibi_workq.c
west build -b <your_board> <your_app> --pristine

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.