Odebrany

CVE-2026-97620

opublikowano: 25.09.2026, 13:17

modyfikacja: 25.09.2026, 13:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

drm/xe: Opróżnij pamięć podręczną portu danych L1 bez typu LSC po wsadach rcs/ccs

emit_render_cache_flush() ustawia PIPE_Control0_HDC_PIPELINE_FLUSH na
opróżnij pamięć podręczną danych L2/HDC przed sygnalizacją ogrodzenia, ale nigdy tego nie robi
żąda opróżnienia pamięci podręcznej LSC bez typu L1 za pośrednictwem pliku „Untyped
Bit włączenia opróżniania pamięci podręcznej portu danych w PIPE_Control DWord0[11].

Zgodnie ze specyfikacją Bspec w trybie rurociągu 3D udokumentowane jest HDC Pipeline Flush
również opróżnij/unieważnij niewpisaną pamięć podręczną L1, ale tylko w zależności od tego, jak
HDC_CHICKEN0[13:11] jest zaprogramowane. Zaczynając od MTL, to sprzęgło
między opróżnianiem potoku HDC a opróżnianiem pamięci podręcznej L1 bez typu nie jest już więcej
obowiązuje w praktyce niezależnie od tego, jak zaprogramowany jest HDC_CHICKEN0, tzw
poleganie na nim nie jest bezpieczne na nowszych platformach, takich jak BMG. Vulkan Mesy
sterownik (anv) założył, że jądro opróżnia obie pamięci podręczne pomiędzy
zgłoszeń i powodowały uszkodzenia widoczne dla użytkowników w aplikacjach takich jak Llama.cpp
z powodu tej luki; teraz działa wokół tego, opróżniając obie pamięci podręczne
ponownie z przestrzeni użytkownika na końcu każdego bufora poleceń.

Poprawność pomiędzy zgłoszeniami w tej samej kolejce zależy od przestrzeni użytkownika
odpowiedzialność i należy do Mesa, a nie do jądra. Jednak dla
bezpieczeństwa, musimy upewnić się, że nieaktualne dane nie mogą wyciekać przez nietypowany L1
pamięć podręczna portu danych po odzyskaniu lub eksmitowaniu pamięci, co wymaga
KMD, aby ją opróżnić przed zwolnieniem pamięci do ponownego użycia.

Przed MTL można było zaprogramować HDC_CHICKEN0 (tak jak już to zrobiono w przypadku
DG2 przez Wa_22010960976/Wa_14013347512), aby niezawodnie utrzymać rurociąg HDC
Flush połączony z nietypowanym opróżnianiem pamięci podręcznej L1, więc te platformy są
nienaruszone. Własny sterownik anv Mesy odkrył, że na MTL HW
rozłączyłem oba niezależnie od sposobu zaprogramowania HDC_CHICKEN0,
i nie mógł przywrócić starego zachowania nawet poprzez spisanie rejestru
ręcznie; zobacz Mesa commit 7c2ff46a4fc3 („anv: nie zapobiegaj wpisywaniu L1
opróżnianie pamięci podręcznej w trybie 3D”). Jądro nie może niezawodnie zażądać opróżnienia
z CS na MTL, więc ogranicz nowy bit PIPE_Control do
GRAPHICS_VERx100 >= 2000 (Xe2 i nowsze), gdzie można na nim polegać.

Jawnie ustaw PIPE_Control0_UNTYPED_DATAPORT_CACHE_FLUSH razem
z PIPE_Control0_HDC_PIPELINE_FLUSH w emit_render_cache_flush() włączone
Xe2 i nowsze, więc pamięć podręczna danych L1 jest znana przed wyczyszczeniem pamięci
dopuszczone do ponownego użycia, bez uzależnienia od nieudokumentowanych
zachowanie HDC_CHICKEN0 specyficzne dla platformy.

Bspec: 56551
(wiśnia wybrana z zatwierdzenia 434514b6fe731e873808297c268fc52cdf4a1ce6)

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)

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve