CVE-2026-74674 in Linux
Resumen
por VulDB • 2026-08-22
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm: corregir la dirección incorrecta en la recuperación directa de tablas de páginas (page table reclaim)
Cuando zap_pte_range recupera una tabla de páginas, ejecuta lo siguiente:
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
y esto es incondicionalmente erróneo: si este código se ejecuta, la dirección *addr* siempre apunta a un elemento más allá del final del rango cubierto por la tabla. El parámetro `addr` se utiliza para vaciar (flush) el TLB (realmente, la caché de estructuras de paginación) con el fin de eliminar las referencias a la tabla que va a ser liberada, y cualquier arquitectura que preste atención al parámetro vaciará una dirección incorrecta. (Aunque seguirán liberando la página correcta).
Creo que vale la pena reflexionar sobre por qué el kernel funciona en absoluto.
Si nos encontramos con la línea de código ofensiva, primero borraremos la entrada PMD (línea 1954, zap_empty_pte_table), luego emitiremos las vaciados pendientes si `force_flush` está activado (tlb_flush_mmu_tlbonly(tlb)), luego omitiremos el reintento en la línea 1979 (¡fue suerte!), y finalmente realizaremos la llamada ofensiva a pte_free_tlb. *O* borraremos la entrada PMD inmediatamente antes de pte_free_tlb (línea 1983, zap_pte_table_if_empty).
Si tenemos vaciados pendientes (es decir, si realmente hemos eliminado las entradas del último nivel) en el momento en que borramos la entrada PMD, entonces el vaciado debería eliminar todas las referencias a la tabla (Linus ciertamente parece pensar que así ocurre en todas las arquitecturas [0]).
La condición bajo la cual no tenemos vaciados acumulados en el momento del borrado es muy compleja (toda la función zap_pte_range tiene un flujo de control absurdamente complejo). Si nos encontramos con este caso erróneo, terminaremos borrando la entrada PMD después de la última vez que se vació el rango, y cualquier CPU puede almacenar en caché una referencia a la tabla de páginas (vacía). Si esto ocurre debido a una lectura o escritura normal, provocaría un segfault, por lo que sería raro. Pero la caché también podría llenarse especulativamente. Luego vaciaríamos la dirección incorrecta y luego liberaríamos y posiblemente reutilizaríamos la tabla.
En x86, incluso vaciando la dirección incorrecta funciona en sistemas Intel sin KPTI porque INVLPG vacía *todas* las cachés de estructuras de paginación, no solo las correspondientes a la dirección objetivo. Pero INVPCID no lo hace, y flush_tlb_one_user utilizará INVPCID si está disponible. Y entonces estamos perdidos (toast). Los sistemas AMD son más susceptibles: configuramos el bit EFER.TCE, lo que hace que incluso INVLPG vacíe solo la dirección de destino.
Creo que esto podría solucionar un problema en ripgrep reportado aquí: https://github.com/BurntSushi/ripgrep/issues/3494
[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
If you want to get best quality of vulnerability data, you may have to visit VulDB.