CVE-2026-80919
NieznaneStreszczenie
W jądrze Linux w sterowniku amdgpu wykryto podatność polegającą na rekurencyjnym blokowaniu mutexu w funkcji amdgpu_devcoredump_format(). Podczas zrzutu zawartości IB z zawieszonego zadania dochodzi do podwójnego zablokowania tego samego obiektu synchronizującego, co może prowadzić do zakleszczenia systemu. Problem został naprawiony przez przeniesienie operacji do osobnej funkcji używającej jednego kontekstu drm_exec.
Ocena ryzyka
Ryzyko polega na możliwym zakleszczeniu (deadlock) jądra podczas obsługi zawieszonego zadania GPU, co może doprowadzić do zawieszenia całego systemu lub zalania bufora jądra komunikatami ostrzegawczymi. W praktyce może to uniemożliwić pracę administratora i wymagać restartu maszyny.
Rekomendacja
Zaleca się jak najszybsze zaktualizowanie jądra Linux do wersji zawierającej poprawkę (commit d6bf4242731219ee08ce54c365631e395486651e) lub zastosowanie odpowiedniego backportu. Należy również sprawdzić, czy w używanym systemie nie występują inne podatności związane z tym sterownikiem.
Inne podatności w Linux kernel
Zobacz wszystkie- CVE-2026-80925Nieznane
W jądrze Linuxa wykryto podatność w mechanizmie VLAN, polegającą na dynamicznej zmianie pola hard_header_len podczas przełączania sprzętowego odciążania VLAN TX. Powoduje to wyścig danych w ścieżkach transmisji bez blokady RTNL, co może prowadzić do błędu skb_under_panic oraz niezgodności między zarezerwowaną przestrzenią nagłówka a faktycznym tworzeniem nagłówka.
- CVE-2026-80924Nieznane
W jądrze Linuxa w module crypto: krb5 funkcje crypto_krb5_prepare_encryption() i crypto_krb5_prepare_checksum() zwalniają bufor zawierający świeżo wygenerowane klucze za pomocą zwykłego kfree(), pozostawiając materiał klucza w zwolnionym obiekcie slab. To może prowadzić do wycieku wrażliwych danych.
- CVE-2026-80923Nieznane
W jądrze Linuxa w sterowniku xhci: dbgtty, jeśli tty_register_driver() zakończy się niepowodzeniem, zwalnia referencję, ale nie ustawia globalnego wskaźnika dbc_tty_driver na NULL, co powoduje ponowne wywołanie unregister podczas wyjścia z modułu. Prowadzi to do użycia po zwolnieniu (use-after-free).
- CVE-2026-80922Nieznane
W jądrze Linuxa w module crypto: qcom-rng, generator liczb losowych nie zezwala na wygenerowanie zera jako wyniku, co czyni jego wyjście odróżnialnym od prawdziwie losowego. Zero jest poprawną liczbą losową i powinno być dozwolone.
- CVE-2026-80921Nieznane
W jądrze Linuxa w KVM: s390 vsie, podczas cieniowania bitów dostępu kryptograficznego z formatu0 apcb (crycb 0 lub 1), bity 64..255 pozostają niezmienione z tego, co jest w stronie vsie w crycb i w apcb. To daje zagnieżdżonemu gościowi potencjalny dostęp do urządzenia, które już nie jest dostępne. Należy wyzerować pozostałe bity.
- CVE-2026-80920Nieznane
W jądrze Linuxa w io_uring, sygnalizacja eventfd jest wykonywana inline, gdy dodawany jest pierwszy wpis do listy pracy, co może prowadzić do problemów, gdy dodanie następuje z kontekstu wakeup handlera. Poprawka dodaje flagę IOU_F_TWQ_IN_WAKE, aby wymusić odroczenie sygnalizacji przez call_rcu_hurry() zamiast sygnalizacji inline.
- CVE-2026-80918Nieznane
W jądrze Linuxa w HID: core, występuje pomyłka typu liczby i wskaźnika dla długich elementów. Gdy fetch_item() jest wywoływany przez hid_scan_report() na elemencie z HID_ITEM_TAG_LONG, przechowuje wskaźnik do danych w item->data.longdata zamiast wartości. Funkcje item_udata() i item_sdata() błędnie zakładają format krótki, co prowadzi do ujawnienia dolnej części wskaźnika jądra jako liczby w dmesg.
- CVE-2026-80917Nieznane
W jądrze Linux wykryto podatność prowadzącą do wyłuskania wskaźnika NULL w sterowniku PCI host-generic na 32-bitowych systemach używających trybu CAM. Podczas skanowania magistrali PCI pierwszy odczyt konfiguracji używa niezainicjalizowanego mapowania, co powoduje awarię systemu (kernel panic). Problem dotyczy braku wywołań zwrotnych add_bus/remove_bus w operacjach CAM, które są wymagane do poprawnego mapowania przestrzeni konfiguracyjnej.
- CVE-2026-80916Nieznane
W jądrze Linux wykryto podatność w mechanizmie KCOV, powodującą uszkodzenie danych i wyścigi na systemach z włączonym PREEMPT_RT. Problem wynika z przechowywania tymczasowych danych stanu KCOV w obszarze per-CPU, co przy zagnieżdżonym przełączaniu kontekstu przez softirq prowadzi do nadpisania stanu. Dodatkowo, w pewnych warunkach inicjalizacji może dojść do awarii jądra lub wycieku pamięci.
- CVE-2026-80915Nieznane
W jądrze Linux w sterowniku drm/xe naprawiono ścieżki alokacji DPT. Usunięto mechanizm awaryjnego przełączania z pamięci VRAM na pamięć systemową, ponieważ nie działał poprawnie i powodował czarny ekran z błędami potoku. Dodatkowo uniknięto używania pamięci stolen ze względu na opóźnienia i ryzyko losowych zawieszeń systemu pod obciążeniem.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format When dumping IB contents from a hung job, amdgpu_devcoredump_format() acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB. Both reservations are reservation_ww_class_mutex objects and neither used a ww_acquire_ctx, which trips lockdep: WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu] Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu] amdgpu_devcoredump_deferred_work+0xea [amdgpu] The two reservations are on different BOs in the captured trace, so the splat is a lockdep-correctness warning, not an observed deadlock. It becomes a real self-deadlock whenever the IB BO shares its dma_resv with the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()): amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler refires every ~2 s and each invocation produces this splat, drowning the kernel ring buffer. Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB dumping into a separate helper that locks the root PD and every IB BO together in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles IB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed by the same BO). Every lock is now a top-level acquire under one ww_acquire_ctx, so the recursive ww_mutex condition is gone, and the per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() dance -- including a BO refcount leak on the amdgpu_bo_reserve() failure path -- is removed. (cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)