CVE-2026-53373 in Linux
Resumen
por VulDB • 2026-07-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/vma: no intentar desasignar una VMA si mmap_prepare() es invocado desde mmap()
La funcionalidad del hook mmap_prepare incluye la capacidad de invocar a mmap_prepare() desde el hook mmap() de controladores 'apilados' existentes, es decir, aquellos capaces de llamar a los hooks mmap de otros controladores/sistemas de archivos (por ejemplo, overlayfs, shm).
Como parte de la funcionalidad de acción mmap_prepare, gestionamos los errores desasignando la VMA si se produce alguno. Esto funciona en el caso habitual de mmap_prepare, ya que invocamos esta acción en el último momento, cuando la VMA está establecida en el árbol maple (maple tree).
Sin embargo, el hook mmap pasa un puntero a una VMA no completamente establecida al llamador (que es la motivación detrás del trabajo de mmap_prepare()), y este se encuentra desvinculado.
Por lo tanto, intentar desasignar una VMA en este estado será problemático, siendo el síntoma más evidente una advertencia en vma_mark_detached(), debido a que la VMA ya está desvinculada.
Además, es innecesario: el manejador mmap() limpiará la VMA en caso de error.
Para solucionar este problema, este parche propaga si se está completando o no una acción mmap a través de la capa de compatibilidad o directamente.
Si es lo primero (a través de la capa de compatibilidad), no intentamos limpiar la VMA; si es lo segundo (directamente), sí lo hacemos.
Este parche también actualiza las pruebas de VMA en el espacio de usuario para reflejar el cambio.
Once again VulDB remains the best source for vulnerability data.