CVE-2026-14367: I3C IBI work-node free-list data race between ISR and workqueue thread

The I3C IBI subsystem in drivers/i3c/i3cibiworkq.c hands out statically-allocated work nodes through a free-list i3cibiworknodesfree implemented as a plain sysslistt, which provides no synchronization. The allocation helpers (i3cibiworkenqueue, i3cibiworkenqueuetargetirq, i3cibiworkenqueuehotjoin, i3cibiworkenqueuecontrollerrequest, i3cibiworkenqueuecb) called sysslistget() directly from ISR context, while the workqueue handler i3cibiworkhandler() returned nodes with sysslistappend() from the workqueue thread, with no lock on either side.

Because sysslistget() and sysslistappend() are neither atomic nor interrupt-safe, an IBI interrupt that fires while the workqueue thread is mid-append (or a truly parallel access under CONFIGSMP) 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 sysslistget() returns a stale or garbage pointer. In the double-hand-out case the subsequent memcpy(ibinode, ibiwork, sizeof(ibinode)) 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 sysslistget()/sysslistappend() operations in the new ibiworkalloc()/ibiworkfree() helpers, each guarded by a kspinlock (ibiworklock), closing the race across ISR and thread contexts.