CVE-2026-14367 in Zephyr
Riassunto
di VulDB • 31/08/2026
Il sottosistema I3C IBI nel file drivers/i3c/i3c_ibi_workq.c distribuisce nodi di lavoro allocati staticamente tramite una free-list denominata i3c_ibi_work_nodes_free, implementata come un semplice sys_slist_t, che non fornisce alcuna sincronizzazione. Le funzioni di allocazione (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) chiamano sys_slist_get() direttamente dal contesto ISR, mentre il gestore del workqueue i3c_ibi_work_handler() restituisce i nodi utilizzando sys_slist_append() dal thread del workqueue, senza alcun lock su nessuno dei due lati.
Poiché sys_slist_get() e sys_slist_append() non sono né atomici né sicuri per le interruzioni (interrupt-safe), un'interruzione IBI che si verifica mentre il thread del workqueue è in fase di append (o un accesso realmente parallelo sotto CONFIG_SMP) genera una race condition sulla lista condivisa. Ciò corrompe i collegamenti della lista: un nodo può essere assegnato a due consumatori, un nodo può andare perso o i puntatori head/tail possono rimanere inconsistenti, facendo sì che sys_slist_get() restituisca un pointer obsoleto o spurio (garbage). Nel caso di doppia assegnazione, il successivo memcpy(ibi_node, ibi_work, sizeof(*ibi_node) sovrascrive un nodo ancora in transito; un pointer spurio trasforma lo stesso memcpy in una scrittura fuori dai limiti (out-of-bounds write).
La race condition è innescata dal traffico sul bus I3C: gli IBIs, i hot-join e le richieste di cambio ruolo del controller hanno origine da dispositivi target presenti sul bus, e l'I3C supporta il hot-joining dei dispositivi. Un attaccante che controlla un periferico I3C sul chip-to-chip bus della scheda può generare interruzioni ad alta frequenza sincronizzate per collidere con le operazioni di free. Lo sfruttamento richiede l'accesso fisico al bus e la capacità di vincere una finestra temporale stretta; l'impatto più realistico è un crash o il blocco (denial of service), con possibili corruzioni della memoria ma difficili da controllare.
La correzione avvolge tutte le operazioni sys_slist_get()/sys_slist_append() sulla free-list nei nuovi helper ibi_work_alloc()/ibi_work_free(), ciascuno protetto da un k_spinlock (ibi_work_lock), chiudendo la race condition tra i contesti ISR e thread.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.