https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 23:26:44 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-97620 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches</p> <p>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 &#39;Untyped Data-Port Cache Flush Enable&#39; bit in PIPE_CONTROL DWord0[11].</p> <p>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&#39;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.</p> <p>Correctness between submissions on the same queue is userspace&#39;s responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can&#39;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.</p> <p>Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches</p> <p>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 &#39;Untyped Data-Port Cache Flush Enable&#39; bit in PIPE_CONTROL DWord0[11].</p> <p>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&#39;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.</p> <p>Correctness between submissions on the same queue is userspace&#39;s responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can&#39;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.</p> <p>Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-97620 https://vulnerability.circl.lu/vuln/ghsa-27vj-fv42-fgqc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches</p> <p>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 &#39;Untyped Data-Port Cache Flush Enable&#39; bit in PIPE_CONTROL DWord0[11].</p> <p>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&#39;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.</p> <p>Correctness between submissions on the same queue is userspace&#39;s responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can&#39;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.</p> <p>Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches</p> <p>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 &#39;Untyped Data-Port Cache Flush Enable&#39; bit in PIPE_CONTROL DWord0[11].</p> <p>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&#39;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.</p> <p>Correctness between submissions on the same queue is userspace&#39;s responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can&#39;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.</p> <p>Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_…</p> https://vulnerability.circl.lu/vuln/ghsa-27vj-fv42-fgqc https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97620 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p> <p>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 &#39;Untyped Data-Port Cache Flush Enable&#39; 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&#39;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&#39;s responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can&#39;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_14013…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p> <p>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 &#39;Untyped Data-Port Cache Flush Enable&#39; 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&#39;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&#39;s responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can&#39;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_14013…</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97620 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579