Vulnerabilidad en kernel de Linux (CVE-2024-53079)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/thp: arregla el bloqueo y el nombre de la cola de separación diferida Los cambios recientes están poniendo más presión en las colas de separación diferida de THP: bajo carga revelando ejecucións de larga data, causando corrupciones de list_del, "Bad page state" y peores (mantengo ERRORES en ambos, por lo que generalmente no llego a ver qué tan mal terminan sin ellos). Los cambios recientes relevantes son mTHP de 6.8, mTHP swapout de 6.10 y mTHP swapin de 6.12, asignación de intercambio mejorada y división de THP infrautilizada. Antes de arreglar el bloqueo: cambia el nombre de folio_undo_large_rmappable() engañoso, que no deshace large_rmappable, a folio_unqueue_deferred_split(), que es lo que hace. Pero eso y su __callee fuera de línea son internos mm de usabilidad muy limitada: agrega comentario y WARN_ON_ONCEs para verificar el uso; y devuelve un bool para decir si una división diferida fue sacada de la cola, que luego se puede usar en WARN_ON_ONCEs alrededor de las verificaciones de seguridad (ahorrando a los llamadores las condicionales arcanas en __folio_unqueue_deferred_split()). Simplemente omite folio_unqueue_deferred_split() de free_unref_folios(), todos cuyos llamadores ahora lo llaman de antemano (y si alguno se olvida, bad_page() lo dirá) - excepto su llamador put_pages_list(), que en sí mismo ya no tiene ningún llamador (y se eliminará por separado). Swapout: mem_cgroup_swapout() ha estado restableciendo folio->memcg_data 0 sin verificar y sacar de la cola un folio THP de la lista de divisiones diferidas; lo cual es desafortunado, ya que split_queue_lock depende de memcg (cuando memcg está habilitado); por lo que swapout ha estado sacando de la cola dichos THP más tarde, al liberar el folio, usando el bloqueo de pgdat en su lugar: potencialmente corrompiendo la lista de memcg. __remove_mapping() ha congelado refcount a 0 aquí, por lo que no hay problema con llamar a folio_unqueue_deferred_split() antes de restablecer memcg_data. Eso se remonta a el commit 5.4 87eaceb3faa5 ("mm: thp: make deferred split reductioner memcg awareness"): que incluía una verificación en swapcache antes de agregar a la cola diferida, pero ninguna verificación en la cola diferida antes de agregar THP a swapcache. Eso funcionó bien con la secuencia habitual de eventos en la recuperación (aunque hubo un par de formas raras en las que un THP en la cola diferida podría haber sido intercambiado), pero el commit 6.12 dafff3f4c850 ("mm: dividir THP subutilizados") evita dividir THP subutilizados en la recuperación, lo que hace que los THP de swapcache en la cola diferida sean algo común. ¿Mantener la verificación en swapcache antes de agregar a la cola diferida? Sí: ya no es esencial, pero conserva el comportamiento existente y es probable que sea una optimización que valga la pena (vmstat mostró mucho más tráfico en la cola bajo carga de intercambio si se eliminó la verificación); actualice su comentario. Movimiento de Memcg-v1 (obsoleto): mem_cgroup_move_account() ha estado cambiando folio->memcg_data sin verificar y sacar de la cola un folio THP de la lista diferida, a veces corrompiendo "de" la lista de memcg, como swapout. Refcount no es cero aquí, por lo que folio_unqueue_deferred_split() solo se puede usar en un WARN_ON_ONCE para validar la corrección, que debe hacerse antes: mem_cgroup_move_charge_pte_range() primero intenta dividir el THP (la división, por supuesto, desencola), o lo omite si eso falla. No es ideal, pero se ha solicitado mover el cargo, y khugepaged debería reparar el THP más tarde: nadie quiere un nuevo código de desencola personalizado solo para este caso obsoleto. el commit 87eaceb3faa5 tenía el código para moverse de una lista diferida a otra (pero no era consciente de su inseguridad mientras refcount no sea 0); pero eso fue eliminado por el commit fac0516b5534 de la versión 5.6 ---- truncado -----