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

  - xhci处理多个流情况的 TD 清除当使用多个流时多个 TD 可能会在端点停止时重新使用。我们需要为每个问题发出“设置 TR 出列指针”，以确保正确重置所有内容并清除缓存。更改逻辑使得发现针对不同流处于活动状态的任何 N>1 TD 都会延迟到第一个 TD 处理完成之后再次从 xhci_handle_cmd_set_deq() 调用 xhci_invalidate_cancelled_tds()以便将另一个命令排入队列直到处理完所有这些命令。此外更改 error/should never emerge 路径以确保至少清除了任何受影响的 TD即使无法发出清除硬件缓存的命令也是如此并在发生时通过 xhci_warn() 强烈抱怨。此问题案例可追溯至 XHCI 驱动程序生命周期早期的提交 e9df17eb1408 (USBxhci正确假设有关每个端点的环数。) 即首次添加流支持时。此问题随后在提交 674f8438c121xhci将处理停止的端点拆分为两个步骤中被识别但未修复亦未生成警告其添加针对问题案例的 FIXME 注释据我所知并未对行为产生重大更改不过新逻辑使问题更明显。之后在提交 94f339147fc3 (xhci修复失败以交还某些缓存已取消的 URB)中再次对其进行了确认。[Mathias: commit 94f339147fc3 (xhci修复失败以交还某些缓存已取消的 URB)。是上述修补程序的针对性回归补丁。用户报告了卸载/断开 UAS 设备连接后 usb 卡住的问题。这将多个流的 TD 清除回滚到其原始状态。] 显然提交作者意识到此问题但仍然选择提交它仍然作为 FIXME提及已添加 xhci_dbg() 以记录问题情况提交描述中提及了剩余的问题。针对目前完全未处理且已知的损坏情况选择创建日志类型 xhci_dbg() 令人费解且不幸因为它保证没有实际的用户会在生产中看到该日志从而使其接近不可调试 (实际上即使打开 DEBUG该消息也不会真正暗示存在问题。我花费了 * 个月 * 的 xHC 崩溃时间才最终找到可靠的重现并能够进行深入的调试会话如果确实通过警告报告这种未处理的损坏情况这一切都可以避免一直作为缺陷有意地保留在未修复中并不在意它根本不应该保留在 中。 > 需要另一个补丁来解决清除所有已取消 TD 的流环的缓存问题但紧迫性不高。在该声明发布 3 年后，以及在引入原始缺陷 14 年后，我想现在是时候修复它了。或许下一次我们一定会修复缺陷实际上比原始缺陷更严重而实际促使人们检查内核提交。修复 UAS 设备在处理错误/故障时的 xHC 崩溃与 IOMMU 错误。
    最简单的重现是使用“hdparm”将磁盘上的早期扇区例如 1024标记为坏然后在循环中标记“cat /dev/sdX > /dev/null”。至少在 JMicron 控制器的情况下读取错误最终必须取消两个 TD针对不同流的两个排队请求而未正确清除的一个错误最终会在尝试访问 DMA 时将 xHC 完全报告为错误此后一直未映射的页面由过时的 TD 引用。这通常很快会发生（两三个循环后）。修复此问题后我让循环中的“cat”整晚运行并且没有遇到 xHC 故障所有读取错误也能正确恢复。在 Apple M1 Mac Minidwc3 主机上进行了复制和测试。在没有 IOMMU 的系统上此缺陷会改为静默损坏已释放的内存从而将此问题成为 ---truncated--- (CVE-2024-40927)

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

检测

Linux Distros 未修补的漏洞：CVE-2024-40927

high Nessus 插件 ID 228480

版本 1.12