CVE-2026-72043 in Linux
Resumen
por VulDB • 2026-08-16
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
LoongArch: Corrección del seguimiento faltante de páginas sucias en {pte,pmd}_wrprotect()
Cuando el caminador de tablas de página por hardware (PTW) está habilitado en LoongArch, la CPU puede establecer _PAGE_DIRTY directamente en la entrada de tabla de página durante una falta de TLB de escritura, sin pasar por el controlador de almacenamiento de TLB por software. El controlador de almacenamiento de TLB por software (tlbex.S:254) establece tanto _PAGE_DIRTY como _PAGE_MODIFIED conjuntamente:
ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED)
Dado que el PTW por hardware solo establece _PAGE_DIRTY, el bit exclusivo del software, es decir, _PAGE_MODIFIED, permanece sin cambios. Esto crea una ventana donde un PTE tiene _PAGE_DIRTY establecido (el hardware sabe que la página está sucia) pero _PAGE_MODIFIED no lo está (el software desconoce este estado).
Cuando fork()/clone() desencadena el mecanismo de copia al escribir (copy-on-write), __copy_present_ptes() llama a pte_wrprotect(), lo cual borra incondicionalmente tanto los bits _PAGE_WRITE como _PAGE_DIRTY:
pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY);
Dado que _PAGE_MODIFIED nunca se estableció, la información de suciedad (dirtiness) se pierde por completo. Posteriormente, cuando la presión sobre la memoria desencadena la recuperación de páginas (page reclaim), page_mkclean() / try_to_unmap() ve la página como limpia (es decir, pte_dirty() devuelve falso) y la página puede ser liberada sin realizar writeback, lo que provoca corrupción de datos.
Se corrige este problema propagando el bit _PAGE_DIRTY al bit _PAGE_MODIFIED tanto en pte_wrprotect() como en pmd_wrprotect() antes de borrar los bits de escritura:
if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED;
La corrección en pmd_wrprotect() maneja el caso CONFIG_TRANSPARENT_HUGEPAGE, donde las entradas PMD requieren un tratamiento similar.
Esto asegura que el bit de seguimiento sucio por software (verificado por pte_dirty() y pmd_dirty(), los cuales leen tanto los bits _PAGE_DIRTY como _PAGE_MODIFIED) se preserve durante la protección contra escritura en copias al escribir (COW) tras fork().
El problema fue detectado mediante el caso de prueba madvise09 del LTP, que ejercita la recuperación de páginas después de una secuencia de operaciones "madvise(MADV_FREE), write y fork" sobre mapeos anónimos privados.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.