Vulnerabilidad en kernel de Linux (CVE-2025-37964)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm: Eliminar la ventana donde los vaciados de TLB pueden omitirse inadvertidamente tl;dr: Hay una ventana en el código de conmutación mm donde se establece el nuevo CR3 y la CPU debería obtener vaciados de TLB para el nuevo mm. Pero should_flush_tlb() tiene un error y suprime el vaciado. Arréglelo ampliando la ventana donde should_flush_tlb() envía una IPI. Versión larga: === Historial === Hubo algunas cosas que llevaron a esto. Primero, se observó que actualizar mm_cpumask() era demasiado costoso, por lo que se hizo más perezoso. Pero ser perezoso causó demasiados IPI innecesarios a las CPU debido al ahora perezoso mm_cpumask(). Entonces se agregó código para descartar mm_cpumask() periódicamente[2]. Pero ese descarte fue demasiado agresivo y omitió el envío de vaciados de TLB a las CPU que los necesitan. Así que aquí estamos de nuevo. === Problema === El código demasiado agresivo en should_flush_tlb() ataca en esta ventana: // Activa las IPI para esta combinación de CPU/mm, pero solo si should_flush_tlb() está de acuerdo: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ Después de que 'need_flush' se establece en falso, las IPI *DEBEN* // enviarse a esta CPU y no ignorarse. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ ¡No es hasta este punto que should_flush_tlb() // se vuelve verdadero! should_flush_tlb() suprimirá los vaciados de TLB entre load_new_mm_cr3() y la escritura en 'loaded_mm', que es una ventana donde no deberían suprimirse. ¡Uy! === Solución === Afortunadamente, la ventana difusa "a punto de escribir CR3" ya está marcada con load_mm==LOADED_MM_SWITCHING. Simplemente comprobar ese estado en should_flush_tlb() es suficiente para asegurar que la CPU esté dirigida a un IPI. Esto provocará más IPI de vaciado de TLB. Sin embargo, la ventana es relativamente pequeña y no preveo que esto tenga ningún impacto medible en el rendimiento. Actualice el comentario donde se escribe LOADED_MM_SWITCHING, ya que ha generado otro usuario. Peter Z también planteó la preocupación de que should_flush_tlb() podría no observar 'loaded_mm' e 'is_lazy' en el mismo orden en que switch_mm_irqs_off() los escribe. Añade una barrera para garantizar que se observen en el orden en que están escritos.