CVE-2026-98919
NieznaneStreszczenie
W jądrze Linux w komponencie drm/xe naprawiono podatność w funkcji adjust_idledly(), która nie obsługiwała przypadków brzegowych. Gdy xe_gt_clock_init() nie rozpozna zegara kryształu, timestamp_base wynosi 0, co prowadzi do dzielenia przez zero i paniki jądra. Dodatkowo konwersje tick-to-ns w u32 mogą powodować przepełnienie, a nieprawidłowe zaokrąglenie może programować wartość opóźnienia większą lub równą maxcnt, wywołując ostrzeżenia przy każdej inicjalizacji.
Ocena ryzyka
Podatność może doprowadzić do paniki jądra (odmowa usługi) na systemach z kartami graficznymi Intel obsługiwanymi przez sterownik drm/xe, szczególnie gdy zegar kryształu nie zostanie rozpoznany. Może to spowodować niedostępność systemu lub usług.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę (commit d864065ea25e9d12897c175de9176ce46677e176 lub nowszej). Jeśli aktualizacja nie jest możliwa, rozważ ograniczenie użycia sterownika drm/xe lub monitorowanie systemów pod kątem panik jądra związanych z tym sterownikiem.
Inne podatności w Linux kernel drm/xe
Zobacz wszystkie- CVE-2025-68802Nieznane
W jądrze Linux w komponencie drm/xe wykryto podatność polegającą na braku ograniczenia wartości num_syncs w ioctl exec i vm_bind. Użytkownik przestrzeni użytkownika może podać dowolnie dużą wartość, co wymusza nadmierną alokację pamięci i generuje ostrzeżenia alokatora stron jądra. Wprowadzono limit DRM_XE_MAX_SYNCS równy 1024 i odrzucanie żądań przekraczających ten limit.
- CVE-2026-98999Wysokie
W jądrze Linux w module drm/xe wykryto błąd polegający na pozostawieniu nieaktualnego wpisu pinned_link, gdy odpięcie bufora ramki (fb-pin) wykonuje ostatnie odpięcie. Prowadzi to do wpisu listy wskazującego na zwolnioną pamięć i potencjalnego use-after-free przy kolejnym przejściu lub modyfikacji listy.
- CVE-2026-98310Niskie ryzyko· EPSS 5%
W jądrze Linux w komponencie drm/xe/shrinker wykryto błąd, w którym funkcja __xe_shrinker_walk() przegląda listy LRU SYSTEM i TT bez referencji runtime PM. Zmniejszanie bufora poza pamięcią systemową unieważnia jego mapowania GPU, co wymaga wybudzenia urządzenia — w stanie uśpienia runtime powoduje to ostrzeżenie asercji i zwrócenie -ENODEV przez unieważnienie TLB.
- CVE-2026-97620Niskie ryzyko· EPSS 9%
W jądrze Linux w sterowniku drm/xe funkcja emit_render_cache_flush() nie żądała opróżnienia nieotypowanej pamięci podręcznej L1 dataport (LSC untyped L1) przed zwolnieniem pamięci do ponownego użycia. Od platformy MTL (Meteor Lake) powiązanie między HDC Pipeline Flush a opróżnieniem tej pamięci podręcznej nie jest już niezawodne, co może prowadzić do wycieku nieaktualnych danych. Poprawka jawnie ustawia bit PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH na platformach Xe2 i nowszych.
- CVE-2026-90047Wysokie
W jądrze Linux w komponencie drm/xe wykryto błąd w funkcji get_flat_ccs_offset(), która zaokrąglała w górę offset końca pamięci VRAM, przez co fragment pamięci należący do sprzętowej kompresji (flat CCS) był udostępniany alokatorowi VRAM jako wolna pamięć. Sprzęt kompresji nadpisywał następnie dane w tym obszarze bez wiedzy sterownika, co prowadziło m.in. do uszkodzenia tablic stron i zawieszenia kompozytora (czarny ekran). Problem dotyczy głównie układów Intel Battlemage G21.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: drm/xe: harden adjust_idledly() against divide-by-zero and overflow adjust_idledly() has several corner-case issues flagged during review: 1. If xe_gt_clock_init() failed to recognise the crystal clock, gt->info.timestamp_base is 0, which makes idledly_units_ps also 0. The subsequent DIV_ROUND_CLOSEST(..., idledly_units_ps) is then a divide-by-zero and panics the kernel. 2. The tick-to-ns conversions are done in u32: idledly * idledly_units_ps, (maxcnt - 1) * 1000 Both overflow u32 before DIV_ROUND_CLOSEST() sees them. 3. If IDLE_WAIT_TIME reads back as 0, maxcnt evaluates to 0 and the maxcnt - 1 clamp wraps to 0xFFFFFFFF in u32. 4. The register only stores whole ticks, so the clamped ns value has to be converted to ticks and back. DIV_ROUND_CLOSEST() can round that conversion up past maxcnt: maxcnt = 640 ns, one tick = 666664 ps clamp: maxcnt - 1 = 639 ns ns -> ticks: 639000 / 666664 = 0.958 -> rounds to 1 tick tick -> ns: 1 * 666664 / 1000 = 667 ns 667 ns is programmed into RING_IDLEDLY, but 667 >= maxcnt (640), so xe_gt_WARN_ON() fires again on every subsequent init. Return early if timestamp_base is 0 (the unknown-crystal path). Do the conversions in u64 via the *_ULL() helpers so they cannot wrap. Clamp with a floor (DIV_ROUND_DOWN_ULL) so the programmed delay stays strictly below maxcnt, and guard the maxcnt == 0 case with a zero delay while still writing RING_IDLEDLY so INHIBIT_SWITCH_UNTIL_PREEMPTED is cleared. v2: Drop the redundant warn on the timestamp_base == 0 path; xe_gt_clock_init() already warns on an unrecognised crystal clock. Keep the early return to avoid the divide-by-zero. - Vinay v3: Field-mask the RING_IDLEDLY write with REG_FIELD_PREP(IDLE_DELAY, ...) instead of writing the raw tick count, which could clobber INHIBIT_SWITCH_UNTIL_PREEMPTED and reserved bits. Split the inhibit-switch clear from the maxcnt clamp so a set inhibit bit no longer forces a needless delay overwrite when the delay itself is already valid. Use gt_to_xe(gt) instead of gt_to_xe(hwe->gt). (cherry picked from commit d864065ea25e9d12897c175de9176ce46677e176)
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

