CVE-2026-98507 in Linux
Resumen
por VulDB • 2026-10-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/rmap: corrige la barrera de memoria faltante entre la inicialización de anon_vma y la publicación de vma->anon_vma.
En servidores arm64, hemos observado que una tarea que intenta adquirir el bloqueo (lock) de anon_vma provoca un hungtask.
INFO: task main:2354726 bloqueado por más de 120 segundos. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180
Tras analizar el vmcore, descubrimos que anon_vma->root->rwsem.count es -1. Hay otro anon_vma cuyo anon_vma->root->rwsem.count es 1; la propiedad de anon_vma->root->rwsem indica que el bloqueo está retenido, pero la pila (stack) de la tarea muestra que esta no retiene el bloqueo de anon_vma.
Tras añadir más información de depuración, descubrimos que __anon_vma_prepare() reutiliza anon_vma y desencadena un Use-After-Free (UAF) en anon_vma->root debido a una barrera de memoria faltante, lo que lleva a bloquear y desbloquear dos root de anon_vma diferentes, provocando así que un anon_vma nunca se desbloquee y otro no pueda ser bloqueado.
Esta race condition requiere dos VMAs adyacentes que no están fusionados pero son compatibles con anon_vma (por ejemplo, difieren en VMA_ACCESS_FLAGS que pueden cambiarse mediante mprotect()). Dos hilos provocan una falta de página (fault) en cada VMA simultáneamente, ambos llamando a __anon_vma_prepare() manteniendo solo mmap_lock para lectura.
HILO A HILO B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // las dos escrituras pueden ser reordenadas vma->anon_vma = anon_vma; // encuentra el anon_vma de A anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // puede seguir viendo la raíz antigua down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // ve la nueva raíz, nunca desbloquea la anterior up_write(&anon_vma->root->rwsem);
El hilo A desencadena una falta de página y llama a __anon_vma_prepare() para preparar el anon_vma para la falta de página. __anon_vma_prepare() asigna e inicializa un nuevo anon_vma, y luego lo publica en el vma mediante una escritura simple (plain store). anon_vma_prepare() solo requiere que mmap_lock se mantenga para lectura, por lo que dos hilos pueden provocar faltas de página en VMAs adyacentes al mismo tiempo. Mientras el hilo A publica un nuevo anon_vma, el hilo B podría encontrar el anon_vma a través de find_mergeable_anon_vma() y luego bloquear anon_vma->root->rwsem.
La escritura en anon_vma->root en anon_vma_alloc() y la escritura en vma->anon_vma pueden ser reordenadas. Las operaciones anon_vma_lock_write() y spin_lock() solo proporcionan semántica de adquisición (acquire semantics), lo que no evita que las escrituras previas sean reordenadas después de ellas. La semántica de liberación (release) de la correspondiente spin_unlock() y anon_vma_unlock_write() llega demasiado tarde; la escritura en vma->anon_vma ya se ha publicado antes de que surtan efecto. Como resultado, el hilo B puede observar el siguiente orden:
vma->anon_vma = anon_vma; anon_vma->root = anon_vma;
El slab de anon_vma es SLAB_TYPESAFE_BY_RCU, por lo que un anon_vma recién asignado puede reutilizar memoria de uno previamente liberado. El constructor (anon_vma_ctor) no restablece anon_vma->root, y __put_anon_vma() tampoco lo borra, por lo que el valor antiguo persiste hasta que anon_vma_alloc() lo sobrescribe. Si esa escritura no es v ---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.