CVE-2024-35980

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: tlb: corrige el operando TLBI RANGE KVM/arm64 se basa en la función TLBI RANGE para vaciar los TLB cuando VMM recopila las páginas sucias y las entradas de la tabla de páginas quedan protegidas contra escritura durante la migración en vivo. . Desafortunadamente, el operando pasado a la instrucción TLBI RANGE no está ordenado correctamente debido a la confirmación 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). Esto provoca un bloqueo en la máquina virtual de destino después de la migración en vivo porque los TLB no se vacían por completo y se omiten algunas de las páginas sucias. Por ejemplo, tengo una máquina virtual a la que se asignan 8 GB de memoria, a partir de 0x40000000 (1 GB). Tenga en cuenta que el host tiene 4 KB como tamaño de página base. En medio de la migración, se ejecuta kvm_tlb_flush_vmid_range() para vaciar los TLB. Pasa MAX_TLBI_RANGE_PAGES como argumento para __kvm_tlb_flush_vmid_range() y __flush_s2_tlb_range_op(). SCALE#3 y NUM#31, correspondientes a MAX_TLBI_RANGE_PAGES, no son compatibles con __TLBI_RANGE_NUM(). En este caso específico, -1 ha sido devuelto por __TLBI_RANGE_NUM() para SCALE#3/2/1/0 y rechazado por el bucle en __flush_tlb_range_op() hasta que la variable @scale se desborda por debajo y se convierte en -9, 0xffff708000040000 se establece como el operando. El operando es incorrecto ya que __TLBI_VADDR_RANGE() lo ordena según @scale y @num no válidos. Solucionelo extendiendo __TLBI_RANGE_NUM() para admitir la combinación de SCALE#3 y NUM#31. Con los cambios, [-1 31] en lugar de [-1 30] se puede devolver desde la macro, lo que significa que los TLB para páginas 0x200000 en el ejemplo anterior se pueden vaciar de una vez con ESCALA#3 y NUM#31. La macro TLBI_RANGE_MASK se elimina porque ya nadie la usa. Los comentarios también se adaptan en consecuencia.