Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-08-31T19:16:45.750Z",
  "pubdate": "2026-08-31T19:16:45.750Z",
  "executiveSummary": "The I3C IBI subsystem, specifically within drivers/i3c/i3c_ibi_workq.c, suffers from a race condition due to the lack of synchronization primitives when accessing the statically-allocated free-list of work nodes (i3c_ibi_work_nodes_free). The implementation utilizes sys_slist_t, which is neither atomic nor interrupt-safe, to manage node allocation and deallocation across different execution contexts.\nThe vulnerability occurs because allocation functions (e.g., i3c_ibi_work_enqueue) are invoked from ISR context, while the workqueue handler (i3c_ibi_work_handler) performs deallocation concurrently. In multi-processor environments or scenarios where interrupts preempt the workqueue thread, the list structure becomes prone to corruption. This can lead to double allocation, node loss, or inconsistent list linkage.\nThe impact ranges from system crashes and hangs (Denial of Service) to potential memory corruption via out-of-bounds writes if a garbage pointer is returned by the corrupted list. Successful exploitation requires an attacker with physical access to the I3C bus, allowing them to craft high-frequency IBI, hot-join, or controller request traffic to time the race condition. This vulnerability poses a risk in systems utilizing chip-to-chip I3C communication where target device behavior is not strictly trusted.",
  "technicalDetails": "The root cause of this vulnerability is the thread-unsafe management of the i3c_ibi_work_nodes_free linked list. The I3C IBI subsystem relies on sys_slist_t for managing work nodes, but it fails to implement necessary locking mechanisms when interacting with this structure from disparate execution contexts: ISR context (for enqueueing operations) and thread context (for the workqueue handler).\nIn the vulnerable implementation, the system uses sys_slist_get() for allocation and sys_slist_append() for returning nodes to the pool. Neither of these functions provides internal serialization. Consequently, an IBI interrupt firing while the i3c_ibi_work_handler is executing an append operation causes a race condition on the head and tail pointers of the list. Because these operations are non-atomic, the list linkage can be left in an incoherent state.\nThe exploitation flow involves the following steps: 1) The attacker monitors the I3C bus traffic and identifies the timing of legitimate IBI or workqueue processing; 2) The attacker issues high-frequency, malicious I3C commands (such as hot-join requests) specifically timed to trigger the ISR-based enqueueing logic exactly when the workqueue thread is mid-append; 3) The race condition forces the internal pointers to become desynchronized. If two consumers receive the same pointer, a subsequent memcpy(ibi_node, ibi_work, sizeof(*ibi_node)) results in a data race on the work node content. If the list corruption yields a pointer to an arbitrary or garbage memory location, the same memcpy operation functions as an out-of-bounds write primitive.\nWhile the primary impact is a system instability or DoS resulting from kernel panics or invalid pointer dereferences, the potential for memory corruption introduces a theoretical vector for integrity compromise if the overwritten memory contains sensitive control structures. The vulnerability is constrained by the necessity of physical access to the I3C bus and the precision required to win the narrow timing window for race condition induction."
}