CVE-2026-14367 in Zephyr
Résumé
par VulDB • 31/08/2026
Le sous-système I3C IBI dans drivers/i3c/i3c_ibi_workq.c distribue des nœuds de travail statiquement alloués via une liste libre i3c_ibi_work_nodes_free implémentée en tant que sys_slist_t simple, qui ne fournit aucune synchronisation. Les assistants d'allocation (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) appellent sys_slist_get() directement depuis le contexte ISR, tandis que le gestionnaire de workqueue i3c_ibi_work_handler() renvoie des nœuds avec sys_slist_append() depuis le thread de la workqueue, sans verrouillage d'aucun côté.
Parce que sys_slist_get() et sys_slist_append() ne sont ni atomiques ni sécurisés pour les interruptions, une interruption IBI qui se produit pendant qu'un append est en cours dans le thread de la workqueue (ou un accès véritablement parallèle sous CONFIG_SMP) crée une condition de course sur la liste partagée. Cela corrompt les liens de la liste : un nœud peut être remis à deux consommateurs, un nœud peut être perdu, ou les pointeurs tête/queue peuvent rester incohérents, faisant en sorte que sys_slist_get() renvoie un pointeur périmé ou erroné. Dans le cas d'une double remise, le memcpy(ibi_node, ibi_work, sizeof(*ibi_node)) qui suit écrase un nœud encore en cours de traitement ; un pointeur erroné transforme ce même memcpy en une écriture hors limites (out-of-bounds write).
La condition de course est provoquée par le trafic du bus I3C — les IBIs, les hot-joins et les demandes de changement de rôle contrôleur proviennent des périphériques cibles sur le bus, et l'I3C prend en charge les hot-join. Un attaquant contrôlant un périphérique I3C sur le bus chip-to-chip de la carte peut générer des interruptions à haute fréquence calibrées pour entrer en collision avec l'opération de libération. L'exploitation nécessite un accès physique au bus et gagner une fenêtre temporelle étroite ; l'impact le plus réaliste est un crash ou un blocage (denial of service), bien qu'une corruption mémoire soit possible mais difficile à contrôler.
La correction enveloppe toutes les opérations sys_slist_get()/sys_slist_append() de la liste libre dans les nouveaux assistants ibi_work_alloc()/ibi_work_free(), chacun protégé par un k_spinlock (ibi_work_lock), fermant ainsi la condition de course entre les contextes ISR et thread.
If you want to get best quality of vulnerability data, you may have to visit VulDB.