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

  - usb：gadget：f_midi：在释放 midi 对象之前取消待定的 IN 工作 f_midi 驱动程序嵌入了一个工作项 （midi->work），其处理程序 f_midi_in_work（） 通过 container_of（） 取消引用包含的 struct f_midi。这项工作由两个站点武装：f_midi_complete（） 用于正常的 IN-endpoint 完成，以及 f_midi_in_trigger（） 用于 ALSA rawmidi 输出流启动。f_midi_disable（） 和 f_midi_unbind（） 均不会取消 midi->work。f_midi_disable（） 仅禁用端点并耗尽in_req_fifo;它不同步工作项，声卡异步释放到 MIDI 对象的最终释放。midi 对象是引用计数 （midi->free_ref），只有在 usb_function 引用和 rawmidi private_data引用都丢弃时才会在 f_midi_free（） 中释放。在 f_midi_unbind（） 中，f_midi_disable（） 在释放声卡之前运行，因此尽管 USB 端点已禁用，rawmidi 设备仍可由开放的子流使用。这类子流上的并发用户空间写入可达到 f_midi_in_trigger（） 并在 f_midi_disable（） 返回后再次排入 midi->work。当最后一个引用终止且 f_midi_free（） 继续进行 kfree（midi） 时，以此方式布防的工作项可能仍处于待定状态，进而让 f_midi_in_work（） 在释放 struct 之后将其取消引用，即释放后使用。因此，取消 f_midi_disable（） 中的 midi->work 是不够的：ALSA 触发路径可在 disable（） 返回后重新武装工作。在 refcount-zero 释放站点取消是两个 arming 源都无法留存的边界，因为到那时保持 midi 对象活动的两个引用都已丢失：USB 端点已禁用，rawmidi 设备已释放。通过在 f_midi_free（） 的 refcount-zero 区块中调用 cancel_work_sync（&midi->work） 来修复此问题，然后嵌入的work_struct与结构的其余部分一起释放。opts->lock 是休眠互斥体，因此允许在其下调用 cancel_work_sync（），并且处理程序采用 MIDI->transmit_lock 而非 opts->lock，因此在其等待正在运行的工作实例完成时不会发生自我死锁。此问题由内部静态分析工具发现。
    (CVE-2026-64584)

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

检测

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

high Nessus 插件 ID 333071

版本 1.8