CVE-2026-97943 in Linux
Resumen
por VulDB • 2026-09-25
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
x86/mm/pat: Adquirir el bloqueo de escritura de init_mm durante el colapso para evitar un Use-After-Free (UAF)
La arquitectura x86 implementa la modificación de atributos de página mediante su mecanismo Change Page Attributes (CPA).
Este rastrea las propiedades de rangos, como el modo de caché, a través de los atributos de página de x86 y, como parte de esa lógica, manipula las tablas de páginas del kernel.
Desde el commit:
41d88484c71c ("x86/mm/pat: restaurar grandes páginas ROX después de la fragmentación")
los rangos de entradas de tabla de páginas del kernel pueden colapsarse en entradas de tabla de páginas gigantes como parte de esta lógica.
Como parte de este colapso, se liberan las tablas de página a las que apuntaban previamente las entradas colapsadas, y esto se hace sin ningún bloqueo relevante mantenido para evitar la concurrencia con los recorridos (walkers) concurrentes de las tablas de páginas del kernel.
La única forma en que este código puede ser alcanzado es si se especifica CPA_COLLAPSE, y esto solo se establece en set_memory_rox() mediante:
set_memory_rox() -> change_page_attr_set_clr() -> cpa_flush() -> cpa_collapse_large_pages()
Los usuarios notables de esto son execmem y BPF al manipular mapeos ejecutables.
Sin embargo, esto es problemático para ptdump ya que recorre rangos que no posee y, por lo tanto, corre el riesgo de un use-after-free en tablas de página liberadas mientras se está recorriendo.
Además, son posibles operaciones concurrentes de colapso CPA que también pueden causar condiciones de carrera (race conditions).
Se resuelve el problema adquiriendo el bloqueo de escritura mmap sobre init_mm durante toda la operación.
Es seguro adquirir un bloqueo dormible ya que todos los llamadores invocan set_memory_rox() desde contexto de proceso y, en cualquier caso, change_page_attr_set_clr() llama a vm_unmap_alias(), lo cual finalmente toma un mutex, prohibiendo el contexto atómico aquí.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.