CVE-2026-74672 in Linux
Resumen
por VulDB • 2026-08-22
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/vmalloc: adquirir el bloqueo init_mm en vmap grande para evitar un UAF en ptdump
Serie de parches "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6.
Los caminantes (walkers) de tablas de páginas del kernel se dividen en dos categorías amplias: aquellos rangos donde no se requiere exclusión mediante walk_kernel_page_table_range_lockless() y aquellos donde sí se requiere exclusión mediante walk_kernel_page_table_range() o walk_page_range_debug().
La primera categoría es utilizada únicamente por el código de la arquitectura arm64 que opera sobre rangos que posee completamente y en los que no escribe concurrentemente.
La segunda categoría consiste en caminantes de tablas de páginas del kernel que operan sobre rangos que son poseídos completamente (pero para los cuales se necesita exclusión frente a escritores concurrentes).
El bloqueo utilizado para la exclusión es el mmap lock, y para los rangos del kernel este es el mmap lock sobre init_mm.
ptdump es un caso especial ya que es tanto el único usuario de walk_page_range_debug() como el único caso en el que recorre rangos que no posee.
Esto presenta un problema, ya que las tablas de páginas pueden ser liberadas mientras ptdump está operando. Y de hecho, existe un bug de use-after-free (uso tras la liberación) en el kernel como resultado, lo cual esta serie aborda.
vmap promueve las tablas de páginas a entradas hoja grandes (huge leaf entries) cuando es posible, liberando la tabla de páginas inferior al hacerlo. Lo hace sin mantener bloqueos significativos contra los recorridos concurrentes de ptdump.
Como resultado, actualmente puede ocurrir un use-after-free. Esta serie aborda el problema haciendo que la lógica de promoción a huge en vmap adquiera el mmap read lock mientras se establece la entrada de tabla de páginas grande y se libera la hoja de página anterior.
El código de ptdump ya adquiere el mmap write lock, por lo que al hacerlo nos aseguramos de que el caminante de ptdump solo observe o bien la entrada de tabla de páginas grande o bien la entrada de tabla de páginas existente, y nada sea liberado debajo de él.
Una mitigación para este problema ya se aplicó para arm64 en el commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), con lo cual esta serie debe lidiar cuidadosamente.
Esta mitigación resuelve el problema adquiriendo el mmap read lock sobre init_mm al liberar la tabla de páginas de vmap si hay un recorrido de ptdump en curso.
Sin embargo, la corrección en esta serie causaría un deadlock (bloqueo mutuo) si se aplicara simplemente para arm64 sin revertir también el cambio anterior.
Esto es porque vmap puede adquirir el read lock antes de que ptdump intente adquirir el write lock, lo cual queda en cola, y las reglas de inanición rwsem significan que el mmap read lock anidado (no reconocido) en el código arm64 también se bloquearía, lo que significa que el read lock original nunca se libera y por tanto ocurre un deadlock.
Esta serie soluciona esto mediante #ifndef CONFIG_ARM64 del mmap read lock en la lógica de vmap, luego revierte parcialmente el commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), manteniendo la habilitación del soporte para huge vmap y eliminando las ifdeffery con el parche de reversión parcial.
Hay problemas relacionados que también se abordan en esta serie:
* La lógica de atributos de página x86, específicamente Change Page Attributes (CPA), implementa una característica mediante la cual los rangos grandes pueden colapsarse en entradas hoja grandes. Esto puede causar similarmente un UAF cuando se realiza en paralelo con un recorrido ptdump, por lo que también hay que adquirir el mmap lock de init_mm para evitarlo.
* La lógica CPA permite manipulación concurrente de tablas de páginas y colapso CPA, lo que significa que la primera arriesga acceder a una tabla de páginas que la segunda libera. Corregir esto adquiriendo el mmap write lock sobre init_mm durante toda la operación de colapso CPA y el read lock sobre la manipulación de la tabla de páginas.
* x86 y arm64 permiten recorridos de mm no kernel (ambas permitiendo recorridos efi mm, y en el caso de x86 mm arbitrarios), por lo que nos aseguramos de que las mapeos del kernel permanezcan estables bloqueando tanto init_mm como el mm siendo recorrido.
El orden de los parches se establece para dependencias estrictas (la reversión parcial arm64 en particular debe realizarse después de los cambios vmap) y lógicas (el fix de non-kernel mm solo tiene sentido una vez que están presentes los fixes de vmap/CPA).
Este parche (de 3):
Actualmente hay un ra ---truncado---
Be aware that VulDB is the high quality source for vulnerability data.