Vulnerabilidad en kernel de Linux (CVE-2023-52934)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups En el commit 34488399fa08 ("mm/madvise: agregar soporte de archivo y shmem a MADV_COLLAPSE") realizamos el siguiente cambio en find_pmd_or_thp_or_none(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL; + if (pmd_none(pmde)) + return SCAN_PMD_NONE; Esto era para uso de las rutas de código de archivo/shmem MADV_COLLAPSE, donde MADV_COLLAPSE podría identificar una hugepage asignada a pte, solo para que khugepaged entrara en carrera, liberara la tabla pte y borrara el pmd. Tales rutas de código incluyen: A) Si encontramos una página compuesta adecuadamente alineada de orden HPAGE_PMD_ORDER ya en el pagecache. B) En retract_page_tables(), si no logramos obtener mmap_lock para el mm/dirección objetivo. En estos casos, collapse_pte_mapped_thp() realmente espera un pmd none (no solo !present), y queremos identificar adecuadamente ese caso separado del caso donde no se encuentra ningún pmd, o es un bad-pmd (por supuesto, muchas cosas podrían suceder una vez que eliminamos mmap_lock, y el pmd podría plausiblemente sufrir múltiples transiciones debido a la intervención de un fallo, división, etc.). En cualquier caso, el código está preparado para instalar un huge-pmd solo cuando la entrada pmd existente es un pte-table-mapping-pmd genuino, o el none-pmd. Sin embargo, la confirmación introduce un agujero lógico; Es decir, hemos permitido que los !none- && !huge- && !bad-pmds se clasifiquen como pte-table-mapping-pmds genuinos. Un ejemplo de fugas de información son las entradas de intercambio. Los valores de pmd no se comprueban de nuevo antes de su uso en pte_offset_map_lock(), que espera nada menos que un pte-table-mapping-pmd genuino. Queremos restablecer la comprobación de !pmd_present() (debajo de la comprobación de pmd_none()), pero debemos tener cuidado con las sutilezas en las transiciones y los tratamientos de pmd por parte de varias arquitecturas. El problema es que __split_huge_pmd_locked() borra temporalmente el bit presente (o marca la entrada como inválida), pero pmd_present() y pmd_trans_huge() aún deben devolver verdadero mientras el pmd esté en este estado transitorio. Por ejemplo, pmd_present() de x86 también verifica _PAGE_PSE, la versión de riscv también verifica el bit _PAGE_LEAF y arm64 también verifica el bit PMD_PRESENT_INVALID. Cubriendo los 4 casos para x86 (todas las verificaciones realizadas en el mismo valor pmd): 1) pmd_present() y pmd_trans_huge(). Lo único que sabemos es que el bit PSE está establecido. O bien: a) No estamos compitiendo con __split_huge_page(), y PRESENT o PROTNONE están establecidos. => huge-pmd. b) Actualmente estamos compitiendo con __split_huge_page(). El peligro aquí es que procedamos como si tuviéramos un huge-pmd, pero en realidad estamos viendo un pte-mapping-pmd. Entonces, ¿cuál es el riesgo de este peligro? La única ruta relevante es: madvise_collapse() -> colapso_pte_mapped_thp(). Donde podríamos informar incorrectamente de "éxito", cuando en realidad la memoria no está respaldada por pmd. Esto no tiene problema, ya que la división podría ocurrir inmediatamente después de una ejecución (realmente) exitosa de madvise_collapse(). Por lo tanto, se puede asumir con seguridad que es huge-pmd. 2) pmd_present() && !pmd_trans_huge(): a) PSE no definido y PRESENT o PROTNONE sí lo están. => pte-table-mapping pmd (o PROT_NONE). b) devmap. Esta rutina puede llamarse inmediatamente después de desbloquear/bloquear mmap_lock, o sin bloqueos (véase khugepaged_scan_mm_slot()), por lo que las comprobaciones VMA anteriores han sido invalidadas. 3) !pmd_present() && pmd_trans_huge(): No es posible. 4) !pmd_present() && !pmd_trans_huge() Ni PRESENT ni PROTNONE se establecen => no presente. He revisado todas las arquitecturas que implementan pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) y esta lógica se traduce aproximadamente ---truncated---