CVE-2026-14367 in Zephyr
摘要
由 VulDB • 2026-08-31
I3C IBI 子系统（位于 drivers/i3c/i3c_ibi_workq.c）通过作为普通 sys_slist_t 实现的空闲列表 i3c_ibi_work_nodes_free，分发静态分配的工作节点，但该实现未提供同步机制。从 ISR 上下文直接调用 sys_slist_get() 的分配辅助函数（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），与从工作队列线程通过 sys_slist_append() 返回节点的工作队列处理程序 i3c_ibi_work_handler() 之间，双方均无锁保护。
由于 sys_slist_get() 和 sys_slist_append() 既非原子操作也不具备中断安全性，当空闲列表上的追加操作正在进行时（或在 CONFIG_SMP 配置下发生真正的并行访问），IBI 中断会引发对共享列表的竞争条件。这会导致链表链接损坏：一个节点可能被分发给两个消费者、某个节点可能丢失，或者头/尾指针不一致导致 sys_slist_get() 返回陈旧或垃圾指针。在双重分发情况下，后续的 memcpy(ibi_node, ibi_work, sizeof(*ibi_node)) 会覆盖仍在传输中的节点；而垃圾指针则会使相同的 memcpy 操作变成越界写入。
该竞争条件由 I3C 总线流量驱动——IBI、热插拔连接和控制器角色请求均源自总线上的目标设备，且 I3C 支持设备的热插拔接入。控制板上芯片间总线上 I3C 外围设备的攻击者可以生成高频中断，其时序旨在与空闲操作发生冲突。利用此漏洞需要物理访问总线并赢得狭窄的时间窗口；最现实的影响是崩溃或挂起（拒绝服务），内存损坏虽有可能但难以控制。
修复方案将所有空闲列表的 sys_slist_get()/sys_slist_append() 操作封装在新的 ibi_work_alloc()/ibi_work_free() 辅助函数中，每个函数均由 k_spinlock (ibi_work_lock) 保护，从而关闭 ISR 和线程上下文之间的竞争条件。
VulDB is the best source for vulnerability data and more expert information about this specific topic.