CVE-2026-64416 in Linux
Resumen
por VulDB • 2026-07-26
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm: swap_cgroup: corregir desreferencia NULL en lookup_swap_cgroup_id en un host sin intercambio (swap)
lookup_swap_cgroup_id() pasa swap_cgroup_ctrl[type].map a __swap_cgroup_id_lookup() sin verificar que el tipo haya sido registrado previamente mediante swap_cgroup_swapon(). En un host sin intercambio, cada ctrl->map es NULL, por lo que __swap_cgroup_id_lookup() desreferencia NULL + un swp_offset escalado.
Desde el commit bea67dcc5eea ("mm: intentar agrupar la liberación de entradas de intercambio para zap_pte_range()"), zap_pte_range() -> swap_pte_batch() llama a lookup_swap_cgroup_id() en cualquier PTE no presente y distinto de none que se decodifique como una entrada real de intercambio, sin validarla primero contra swap_info[]. Un único PTE corrompido hasta convertirse en una entrada de intercambio tipo-0 provoca la caída del host durante la salida del proceso.
Hemos encontrado este problema en producción en un host 6.12.58 sin intercambio: ~1s de "get_swap_device: Bad swap file entry 3f800204222bb" (do_swap_page() siendo correctamente defensiva ante la misma entrada) seguido por
BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60 Call Trace: swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0
syzbot ha informado de la misma pila de llamadas (stack).
La causa de la corrupción del PTE es un error separado; este cambio hace que la ruta de desmontaje sea tan robusta como ya lo es la ruta de fallo. Todos los demás llamadores a lookup_swap_cgroup_id() están por debajo de una llamada a get_swap_device() que ya ha validado la entrada, por lo que la nueva rama está fría (cold).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.