Description
In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches

emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to
flush the L2/HDC data cache before fence signalling, but it never
requests a flush of the LSC untyped L1 data cache via the 'Untyped
Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11].

Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to
also flush/invalidate the untyped L1 cache, but only depending on how
HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling
between HDC Pipeline Flush and the untyped L1 cache flush no longer
holds in practice, regardless of how HDC_CHICKEN0 is programmed, so
relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan
driver (anv) has been assuming the kernel flushes both caches between
submissions, and hit user-visible corruption in apps such as Llama.cpp
because of this gap; it now works around it by flushing both caches
again from userspace at the end of every command buffer.

Correctness between submissions on the same queue is userspace's
responsibility and belongs in Mesa, not the kernel. However, for
security we must ensure stale data can't leak through the untyped L1
dataport cache once memory is reclaimed or evicted, which requires the
KMD to flush it before releasing memory for reuse.

Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for
DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline
Flush coupled to the untyped L1 cache flush, so those platforms are
unaffected. Mesa's own anv driver found that on MTL the HW
disconnected the two independently of how HDC_CHICKEN0 is programmed,
and could not bring the old behavior back even by writing the register
by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped
cache flush in 3D mode"). The kernel can't reliably request the flush
from the CS on MTL either, so restrict the new PIPE_CONTROL bit to
GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on.

Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together
with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on
Xe2 and later, so the L1 data cache is known clean before memory is
released for reuse, without depending on undocumented
platform-specific HDC_CHICKEN0 behavior.

Bspec: 56551
(cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)
Published: 2026-09-25
Score: n/a
EPSS: n/a
KEV: No
Impact: Data and memory corruption due to stale cache contents
Action: Apply Kernel Update
AI Analysis

Impact

The kernel function emit_render_cache_flush() incorrectly omitted a request to flush the LSC untyped L1 dataport cache on newer Intel Xe2 and later GPUs. As a result, memory that has been released or evicted could still contain stale data in the L1 cache, which may be reused by another allocation. The consequence is that future userspace processes—including Vulkan applications such as Llama.cpp—may read incorrect or corrupted data, leading to crashes, incorrect results, or potential leakage of sensitive information. The flaw does not provide immediate privilege escalation, but it undermines data integrity and confidentiality in graphics workloads.

Affected Systems

Linux kernel builds running on Intel Xe2 and newer graphics hardware (e.g., BMG, MTL). The issue is present in kernels prior to the patch that added an explicit UNFLIPPED_DATAPORT_CACHE_FLUSH bit in PIPE_CONTROL alongside HDC_PIPELINE_FLUSH. No specific kernel versions are listed, so any distribution using a kernel without the patch on a Xe2+ device is potentially affected.

Risk and Exploitability

The flaw relies on a missing hardware cache flush that must be triggered by kernel code. An attacker would need to cause memory to be released within the graphics subsystem and then read L1 cache contents, which typically requires elevated privileges or a user‑level vector that can influence the workload execution order. The EPSS score is unavailable and the vulnerability is not in CISA's KEV list, suggesting low to moderate exploit likelihood. The CVSS score is not reported, but the impact is limited to data corruption or leakage rather than arbitrary code execution.

Generated by OpenCVE AI on September 25, 2026 at 13:22 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update to a Linux kernel that includes the patch adding PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH for Xe2 and newer GPUs.
  • Install the latest Mesa drivers, which perform an additional userspace flush of both L1 and L2 caches after each command buffer to mitigate the issue if a kernel upgrade is not immediately possible.
  • Verify that the device’s graphics firmware and driver configuration enable the new PIPE_CONTROL bit only on supported hardware (GRAPHICS_VERx100 >= 2000) to avoid unintended side effects.

Generated by OpenCVE AI on September 25, 2026 at 13:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 25 Sep 2026 13:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-573

Fri, 25 Sep 2026 10:30:00 +0000

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T10:22:26.242Z

Reserved: 2026-09-24T16:01:01.159Z

Link: CVE-2026-97620

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:16.240

Modified: 2026-09-25T11:17:16.240

Link: CVE-2026-97620

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T13:30:19Z

Weaknesses
  • CWE-573

    Improper Following of Specification by Caller