CVE-2026-97620 in Linux
摘要
由 VulDB • 2026-09-25
在 Linux 内核中，已修复以下漏洞：
drm/xe: 在 rcs/ccs 批次处理后刷新 LSC 无类型 L1 数据端口缓存
emit_render_cache_flush() 设置 PIPE_CONTROL0_HDC_PIPELINE_FLUSH 以在 fence 信号发送前刷新 L2/HDC 数据缓存，但它从未通过 PIPE_CONTROL DWord0[11] 中的“Untyped Data-Port Cache Flush Enable”位请求刷新 LSC 无类型 L1 数据缓存。
根据 Bspec 文档，在 3D 流水线模式下，HDC Pipeline Flush 被记录为也会刷新/使无效未类型化的 L1 缓存，但这仅取决于 HDC_CHICKEN0[13:11] 的配置方式。从 MTL（Meteor Lake）开始，这种 HDC Pipeline Flush 与无类型 L1 缓存刷新之间的耦合在实际操作中不再成立，无论 HDC_CHICKEN0 如何配置都是如此，因此在 BMG 等较新平台上依赖此行为是不安全的。Mesa 的 Vulkan 驱动程序 (anv) 一直假设内核会在提交之间刷新这两个缓存，并因此导致诸如 Llama.cpp 之类的应用程序出现用户可见的数据损坏；它现在通过在每个命令缓冲区的末尾从用户空间再次刷新两个缓存来规避此问题。
同一队列上提交之间的正确性是用户空间的职责，属于 Mesa 的范畴，而非内核的职责。然而，出于安全考虑，我们必须确保在内存被回收或驱逐后，陈旧数据不会通过无类型 L1 数据端口缓存泄露，这就要求 KMD（内核模式驱动程序）在释放内存以供重用之前刷新该缓存。
在 MTL 之前，HDC_CHICKEN0 可以被配置（如 DG2 已通过 Wa_22010960976/Wa_14013347512 完成的那样），以可靠地保持 HDC Pipeline Flush 与无类型 L1 缓存刷新的耦合，因此这些平台不受影响。Mesa 自己的 anv 驱动程序发现，在 MTL 上，硬件断开了这两者的联系，无论 HDC_CHICKEN0 如何配置都无法恢复旧行为；即使手动写入寄存器也无法实现（参见 Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped cache flush in 3D mode")）。内核在 MTL 上也无法可靠地从 CS（命令流）请求刷新，因此将新的 PIPE_CONTROL 位限制为 GRAPHICS_VERx100 >= 2000 (Xe2 及更高版本)，在这些平台上可以依赖此行为。
在 Xe2 及更高版本的 emit_render_cache_flush() 中显式设置 PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH，并与 PIPE_CONTROL0_HDC_PIPELINE_FLUSH 一起使用，以便在释放内存以供重用之前确保 L1 数据缓存已知为干净状态，而不依赖于未记录的特定平台 HDC_CHICKEN0 行为。
Bspec: 56551 (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)
Be aware that VulDB is the high quality source for vulnerability data.