CVE-2026-97620

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches<br /> <br /> emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to<br /> flush the L2/HDC data cache before fence signalling, but it never<br /> requests a flush of the LSC untyped L1 data cache via the &amp;#39;Untyped<br /> Data-Port Cache Flush Enable&amp;#39; bit in PIPE_CONTROL DWord0[11].<br /> <br /> Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to<br /> also flush/invalidate the untyped L1 cache, but only depending on how<br /> HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling<br /> between HDC Pipeline Flush and the untyped L1 cache flush no longer<br /> holds in practice, regardless of how HDC_CHICKEN0 is programmed, so<br /> relying on it is not safe on newer platforms such as BMG. Mesa&amp;#39;s Vulkan<br /> driver (anv) has been assuming the kernel flushes both caches between<br /> submissions, and hit user-visible corruption in apps such as Llama.cpp<br /> because of this gap; it now works around it by flushing both caches<br /> again from userspace at the end of every command buffer.<br /> <br /> Correctness between submissions on the same queue is userspace&amp;#39;s<br /> responsibility and belongs in Mesa, not the kernel. However, for<br /> security we must ensure stale data can&amp;#39;t leak through the untyped L1<br /> dataport cache once memory is reclaimed or evicted, which requires the<br /> KMD to flush it before releasing memory for reuse.<br /> <br /> Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for<br /> DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline<br /> Flush coupled to the untyped L1 cache flush, so those platforms are<br /> unaffected. Mesa&amp;#39;s own anv driver found that on MTL the HW<br /> disconnected the two independently of how HDC_CHICKEN0 is programmed,<br /> and could not bring the old behavior back even by writing the register<br /> by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don&amp;#39;t prevent L1 untyped<br /> cache flush in 3D mode"). The kernel can&amp;#39;t reliably request the flush<br /> from the CS on MTL either, so restrict the new PIPE_CONTROL bit to<br /> GRAPHICS_VERx100 &gt;= 2000 (Xe2 and later), where it can be relied on.<br /> <br /> Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together<br /> with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on<br /> Xe2 and later, so the L1 data cache is known clean before memory is<br /> released for reuse, without depending on undocumented<br /> platform-specific HDC_CHICKEN0 behavior.<br /> <br /> Bspec: 56551<br /> (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)