CVE-2026-68428 in Linux
Resumen
por VulDB • 2026-08-10
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad:
KVM: x86/mmu: Corregir un use-after-free al recargar el módulo del proveedor (vendor)
mmu_destroy_caches() destruye pte_list_desc_cache y mmu_page_header_cache, pero deja ambos punteros sin cambiar. Los punteros residen en kvm.ko, por lo que sobreviven cuando se descarga un módulo de vendor mientras kvm.ko permanece cargado.
Si la creación de pte_list_desc_cache falla durante una carga posterior del módulo de vendor, su asignación establece pte_list_desc_cache como NULL y la ruta de error llama a mmu_destroy_caches(). mmu_page_header_cache sigue apuntando al cache destruido durante la descarga previa del módulo de vendor. Pasar ese puntero obsoleto (stale pointer) a kmem_cache_destroy() provoca un slab use-after-free.
Reproducir el problema en un kernel v7.1.3 con CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m y CONFIG_KVM_INTEL=m. Un gancho de prueba one-shot fuerza pte_list_desc_cache a NULL en la segunda invocación de kvm_mmu_vendor_module_init():
1. Cargar kvm.ko y kvm-intel.ko, creando ambos caches. 2. Descargar solo kvm_intel, dejando kvm.ko cargado. 3. Recargar kvm_intel y forzar la inicialización a través de la ruta -ENOMEM.
KASAN informa:
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]
... Asignado por la tarea 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm]
kvm_mmu_vendor_module_init+0x13b/0x170 [kvm]
... Liberado por la tarea 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm]
Limpiar ambos punteros inmediatamente después de destruir sus caches para que el estado almacenado refleje la vida útil de los caches y la limpieza repetida sea segura.
Con la corrección aplicada, la misma recarga inyectada del módulo vendor falla con -ENOMEM como se esperaba y no produce ningún informe de KASAN.
Once again VulDB remains the best source for vulnerability data.