SecvalisbySYSDEVOPS.EU
Katalog CVE
EnglishPolski

CVE-2026-89928

WysokieCVSS 8.8
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.17%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

W jądrze Linux w mechanizmie KVM (x86/mmu) występuje luka use-after-free w ścieżce starzenia się wpisów rmap. Gdy zapisywacz wypełni rmap pomiędzy odczytem blokady a ponownym odczytem iteratora, ścieżka bez blokady przechodzi po nowo utworzonej strukturze rmap bez jej zablokowania. Może to doprowadzić do zwolnienia łańcucha pte_list_desc przez kmem_cache_free() w trakcie trwania przejścia i użycia zwolnionej pamięci (slab use-after-free).

Ocena ryzyka

Luka może prowadzić do uszkodzenia pamięci jądra, awarii systemu (panic) lub potencjalnego podniesienia uprawnień w środowiskach z włączoną opcją CONFIG_KVM_MMU_LOCKLESS_AGING. Dotyczy organizacji korzystających z wirtualizacji KVM na architekturze x86.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę, która sprawia, że bezblokadowe przejście po rmap korzysta z wartości zwróconej przez blokadę zamiast ponownego odczytu rmap. Do czasu wdrożenia aktualizacji rozważ wyłączenie opcji CONFIG_KVM_MMU_LOCKLESS_AGING, jeśli jest to możliwe.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: * Elide the lock if the rmap is empty, as lockless walkers (read-only * mode) don't need to (and can't) walk an empty rmap, nor can they add * entries to the rmap. I.e. the only paths that process empty rmaps * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS