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

  - drm/xe：不要将平面 CCS 存储作为可用 VRAM get_flat_ccs_offset（） 从硬件读取平面 CCS 存储的基础，按启用的 L3 节点数量对其进行缩放，并将结果四舍五入到 128K。然后，低于该偏移量的所有内容都会作为可用内存传递给 VRAM 分配器。舍入一个限值（这意味着可用内存在此向上结束）会将位于实际基数和舍入后底值之间的任何内容发布为空闲内存，并且该内存属于压缩硬件。缩放值没有理由对齐 128K，而在 16 GiB 的 Battlemage G21 上则不是：平坦的 CCS 基础：原始0x3fafff800，四舍五入0x3fb000000因此页面0x3fafff000的最后 2 KiB 是分配器池中的 CCS 存储。
    无论在那里分配什么，都会被压缩硬件覆盖该尾部，它不需要页表条目、缓冲区对象和 GPU 提交来完成它，并且在用户空间存在之前完成。在此计算机上，每次冷启动时，Mesa VM 的第 3 级页表都会登陆该页面。它丢失了覆盖合成程序批处理缓冲区堆的条目，因此合成程序的首次提交提取其批次时发生错误，并且 gdm 会永远重新启动它：在其他情况下正常工作的计算机上出现黑屏。重新启动 gdm 会清除它，因为下一个 VM 的页表被分配在其他地方。相反，向下舍入到分配器工作的页面大小。在这台计算机上，它恰好排除了一页。之后读取保留的页面会显示一直在写入它的内容：[369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000压缩元数据，每十六个字节两个字节，位于驱动程序用于分发内存的位置。应该抓住这一点的断言将偏移量与 GSMBASE 进行比较 - 相等ccs_size。该值是 128K 对齐的，因此当基数未对齐时，它与舍入的偏移量完全一致 - 在存在捕获的情况下，检查不会失败，并且除非设置了CONFIG_DRM_XE_DEBUG，否则会被编译出来。将其替换为可能失败的：CCS 存储不得与 GSM 冲突。[ 这是一场来自地狱的调试会话，人工智能完成了大部分繁重的工作，为他提供了巨大的帮助。我想称它为我不知疲倦的帮手，但人工智能多次直言不讳地表示这是不可能和无法解决的，我们应该写一份关于它的报告。我怀疑这些东西是由可能不像我那么固执的人训练的。但是，虽然 AI 已经做好了几次放弃的准备，但它确实在我推动时不断添加调试代码并忠实地分析它。因此，在应得的功劳中归功于我，我让 AI 写下上面的提交消息。这基本上是将虚假的 round_up（） 修复为 round_down（） 的单行，但有 24 个修补程序为此添加了越来越多的调试信息，还有 18 个内核引导最终将范围缩小到此范围。- 莱纳斯 ] （CVE-2026-90047）

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

检测

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

high Nessus 插件 ID 346618

版本 1.15