Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - usb：gadget：udc：bdc：拆卸前释放 IRQ 并耗尽 func_wake_notify Broadcom BDC UDC 驱动程序通过 bdc_udc_init（） 中的 devm_request_irq（） 注册其 IRQ 处理程序，因此只有在 bdc_remove（） 返回后才 devm 释放 IRQ。devm 以反向 LIFO 顺序释放资源，但 bdc_remove（） 在返回之前手动运行 bdc_udc_exit（） 和 bdc_hw_exit（） -> bdc_mem_free（），然后返回： bdc_udc_exit（） 通过 bdc_free_ep（） 去除各个端点对象，而 bdc_hw_exit（） -> bdc_mem_free（） 释放 DMA 一致的状态报告环 （bdc->srr.sr_bds） 和 kfree（） 的 bdc->bdc_ep_array 并使其为空。当 IRQ 处理程序（bdc_udc_interrupt，通过 IRQF_SHARED 请求）在窗口中保持可交付状态直到删除后 devm free_irq（） 时，这两种情况都会发生。收到该窗口中的共享中断时，bdc_udc_interrupt（） 会取消引用 bdc->srr.sr_bds[bdc->srr.dqp_index]（空或已释放的 DMA），并调度索引为 bdc_ep_array 的 sr_handler 回调，从而造成空取消引用或释放后使用。同一窗口影响delayed_work bdc->func_wake_notify，它通过 bdc_sr_uspc（） -> handle_link_state_change（） -> schedule_delayed_work（） 从 IRQ 处理程序布防，也可从其自己的回调 bdc_func_wake_timer（） 自我布防。驱动程序中任何地方都不存在取消，因此在 bdc_remove（） 返回后触发的排队工作项且 bdc 结构为 devm 释放取消引用已释放的内存。将 devm_request_irq（） 替换为 request_irq（），并在 bdc_remove（） 中添加明确的 free_irq（bdc->irq， bdc）。在 free_irq（） 之前清除 BDC_GIE 以阻止设备断言中断，然后 free_irq（） 耗尽任何正在运行的处理程序，然后 cancel_delayed_work_sync（） 耗尽func_wake_notify延迟的工作。此排序可确保 IRQ 处理程序和延迟的工作不会干扰 bdc_udc_exit（） 和 bdc_hw_exit（） 中的后续端点和 DMA 拆卸。将匹配的 free_irq（） 连接到 bdc_udc_init（） 错误路径，以便在探测失败时释放 IRQ，并通过 err0 路由 bdc_init_ep（） 失败，而不是直接返回。此问题由内部静态分析工具发现。（CVE-2026-64583）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-64583

high Nessus 插件 ID 333068

版本 1.3