CVE-2026-14367 in Zephyr
Summary
by MITRE • 08/31/2026
The I3C IBI subsystem in drivers/i3c/i3c_ibi_workq.c hands out statically-allocated work nodes through a free-list i3c_ibi_work_nodes_free implemented as a plain sys_slist_t, which provides no synchronization. The allocation helpers (i3c_ibi_work_enqueue, i3c_ibi_work_enqueue_target_irq, i3c_ibi_work_enqueue_hotjoin, i3c_ibi_work_enqueue_controller_request, i3c_ibi_work_enqueue_cb) called sys_slist_get() directly from ISR context, while the workqueue handler i3c_ibi_work_handler() returned nodes with sys_slist_append() from the workqueue thread, with no lock on either side.
Because sys_slist_get() and sys_slist_append() are neither atomic nor interrupt-safe, an IBI interrupt that fires while the workqueue thread is mid-append (or a truly parallel access under CONFIG_SMP) races on the shared list. This corrupts the list linkage: a node may be handed to two consumers, a node may be lost, or the head/tail pointers may be left inconsistent so sys_slist_get() returns a stale or garbage pointer. In the double-hand-out case the subsequent memcpy(ibi_node, ibi_work, sizeof(*ibi_node)) overwrites a node still in flight; a garbage pointer turns the same memcpy into an out-of-bounds write.
The race is driven by I3C bus traffic — IBIs, hot-joins, and controller-role requests originate from target devices on the bus, and I3C supports hot-joining devices. An attacker controlling an I3C peripheral on the board's chip-to-chip bus can generate high-frequency interrupts timed to collide with the free operation. Exploitation requires physical access to the bus and winning a narrow timing window; the most realistic impact is a crash or hang (denial of service), with memory corruption possible but hard to control.
The fix wraps all free-list sys_slist_get()/sys_slist_append() operations in the new ibi_work_alloc()/ibi_work_free() helpers, each guarded by a k_spinlock (ibi_work_lock), closing the race across ISR and thread contexts.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified within the I3C In-Band Interrupt subsystem represents a critical concurrency flaw rooted in improper synchronization of shared data structures during interrupt handling and workqueue processing. The core issue lies in the implementation of the free-list mechanism, specifically i3c_ibi_work_nodes_free, which is structured as a plain sys_slist_t without any associated locking primitives. This design oversight creates a race condition where multiple execution contexts attempt to modify the same linked list simultaneously. Specifically, allocation helpers such as i3c_ibi_work_enqueue and its variants are invoked from Interrupt Service Routine context using sys_slist_get(), while the corresponding workqueue handler, i3c_ibi_work_handler, returns nodes back to the pool via sys_slist_append() within a thread context. Since neither of these operations is atomic nor interrupt-safe under symmetric multiprocessing configurations or even in single-processor systems with preemption enabled, concurrent access leads to undefined behavior and data structure corruption.
From a technical perspective, this flaw maps directly to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, specifically involving race conditions on shared memory structures. The absence of mutual exclusion allows an IBI interrupt to fire precisely while the workqueue thread is in the middle of appending a node back to the free list. This temporal overlap results in corrupted list linkage where pointers may become inconsistent or point to invalid memory regions. In scenarios where CONFIG_SMP is enabled, parallel access exacerbates this issue, potentially leading to double-free conditions or use-after-free vulnerabilities if a node is handed out to two different consumers simultaneously. The subsequent memcpy operation that copies data from the work structure to the IBI node can then overwrite memory still in flight or write to an out-of-bounds address if a garbage pointer was returned due to list corruption, leading to severe memory integrity violations.
The operational impact of this vulnerability is primarily centered on system stability and availability rather than direct remote code execution. An attacker with physical access to the I3C bus can exploit this race condition by generating high-frequency interrupts through controlled peripheral devices that support hot-joining capabilities. By carefully timing these interrupts to collide with the free-list operations, an adversary can trigger list corruption that results in kernel panics, system hangs, or denial of service conditions. While memory corruption is theoretically possible and could potentially be leveraged for privilege escalation depending on the specific memory layout and subsequent exploitation techniques, the narrow timing window required makes reliable exploitation difficult. This aligns with ATT&CK technique T1498.002, Network Denial of Service: Reflection Amplification, adapted to a physical bus context where resource exhaustion or system instability is achieved through precise interrupt manipulation rather than network flooding.
Mitigation strategies focus on enforcing strict synchronization between the interrupt context and the workqueue thread. The recommended fix involves wrapping all access points to the free-list with atomic operations protected by a dedicated spinlock, specifically ibi_work_lock in this implementation. By introducing helper functions like ibi_work_alloc() and ibi_work_free(), which encapsulate the sys_slist_get() and sys_slist_append() calls within critical sections guarded by k_spinlock, the race condition is effectively eliminated. This ensures that only one execution context can modify the free-list at any given time, preserving data integrity across both interrupt-driven and thread-driven operations. System administrators should apply patches that include these synchronization primitives to restore safe operation of the I3C subsystem, particularly in environments where physical access controls are not strictly enforced or where hot-joining devices are actively used on chip-to-chip buses.