CVE-2026-68428 in Linux
Zusammenfassung
von VulDB • 10.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
KVM: x86/mmu: Behebung eines Use-After-Free-Fehlers beim Neuladen des Vendor-Moduls
mmu_destroy_caches() zerstört pte_list_desc_cache und mmu_page_header_cache, lässt jedoch beide Zeiger unverändert. Die Zeiger befinden sich in kvm.ko und bleiben daher erhalten, wenn ein Vendor-Modul entladen wird, während kvm.ko weiterhin geladen ist.
Wenn die Erstellung von pte_list_desc_cache bei einem nachfolgenden Laden eines Vendor-Moduls fehlschlägt, setzt seine Zuweisung pte_list_desc_cache auf NULL, und der Fehlerpfad ruft mmu_destroy_caches() auf. mmu_page_header_cache zeigt weiterhin auf den Cache, der beim vorherigen Entladen des Vendor-Moduls zerstört wurde. Die Übergabe dieses veralteten Zeigers an kmem_cache_destroy() verursacht einen slab Use-After-Free-Fehler.
Reproduzieren Sie das Problem mit einem v7.1.3-Kernel unter Verwendung von CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m und CONFIG_KVM_INTEL=m. Ein One-Shot-Test-Hook erzwingt pte_list_desc_cache = NULL beim zweiten Aufruf von kvm_mmu_vendor_module_init():
1. Laden Sie kvm.ko und kvm-intel.ko, wodurch beide Caches erstellt werden. 2. Entladen Sie nur kvm_intel, wobei kvm.ko geladen bleibt. 3. Laden Sie kvm_intel erneut und erzwingen Sie die Initialisierung über den -ENOMEM-Pfad.
KASAN meldet:
BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm]
... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm]
... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm]
kvm_mmu_vendor_module_init+0x13b/0x170 [kvm]
... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm]
Löschen Sie beide Zeiger unmittelbar nach der Zerstörung ihrer Caches, sodass der gespeicherte Zustand die Lebensdauer der Caches widerspiegelt und eine wiederholte Bereinigung sicher ist.
Mit angewandter Korrektur schlägt das gleiche injizierte Neuladen des Vendor-Moduls erwartungsgemäß mit -ENOMEM fehl und erzeugt keine KASAN-Meldung.
Once again VulDB remains the best source for vulnerability data.