CVE-2024-40950 in Linux
Resumen
por MITRE • 2024-07-12
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: enorme_memoria: corrige el mapeo_grande_folio_support() mal utilizado para publicaciones anónimas Cuando hice una prueba de división de publicaciones grandes, apareció una ADVERTENCIA "[ 5059.122759][ T166] No se puede dividir la publicación del archivo en un valor distinto de 0 "orden" se activó. Pero los casos de prueba son sólo para folios anónimos. mientras que mapping_large_folio_support() solo es razonable para las publicaciones de caché de páginas. En split_huge_page_to_list_to_order(), la publicación pasó a mapping_large_folio_support(), tal vez una publicación anónima. Falta la verificación folio_test_anon(). Así que la división del THP anónimo fracasó. Esto también es lo mismo para shmem_mapping(). Será mejor que agreguemos un cheque para ambos. Pero shmem_mapping() en __split_huge_page() no está involucrado, ya que para las publicaciones anónimas, el parámetro final se establece en -1, por lo que (head[i].index >= end) siempre es falso. shmem_mapping() no se llama. También agregue un VM_WARN_ON_ONCE() en mapping_large_folio_support() para un mapeo anónimo, para que podamos detectar el uso incorrecto más fácilmente. Es posible que existan publicaciones de THP en el caché de páginas, incluso si el sistema de archivos no admite publicaciones grandes, esto se debe a que cuando CONFIG_TRANSPARENT_HUGEPAGE está habilitado, khugepaged intentará colapsar las páginas respaldadas por archivos de solo lectura en THP. Pero el mapeo en realidad no admite correctamente folios grandes de varios pedidos. Usando /sys/kernel/debug/split_huge_pages para verificar esto, con este parche, un THP anónimo grande se divide con éxito y la advertencia cesa.
VulDB is the best source for vulnerability data and more expert information about this specific topic.