CVE-2024-39483

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: WARN en la ventana vNMI + NMI si los NMI están completamente enmascarados Al solicitar una ventana NMI, WARN en la ventana de vNMI está habilitado si y solo si los NMI están realmente enmascarados, es decir, si la vCPU ya está manejando una NMI. La ABI de KVM para NMI que llegan simultáneamente (desde el punto de vista de KVM) es inyectar un NMI y esperar el otro. Cuando se usa vNMI, KVM suspende el segundo NMI simplemente configurando V_NMI_PENDING y deja que la CPU haga el resto (el hardware configura automáticamente V_NMI_BLOCKING cuando se inyecta un NMI). Sin embargo, si KVM no puede inyectar inmediatamente una NMI, por ejemplo, porque la vCPU está en una sombra STI o se está ejecutando con GIF=0, entonces KVM solicitará una ventana NMI y activará el WARN (pero seguirá funcionando correctamente). Es discutible si el caso GIF=0 tiene sentido o no, ya que la intención del comportamiento de KVM es proporcionar una funcionalidad lo más cercana posible al hardware real. Por ejemplo, si se envían dos NMI en rápida sucesión, la probabilidad de que ambos NMI lleguen a una sombra de STI es infinitamente baja en hardware real, pero significativamente mayor en un entorno virtual, por ejemplo, si la vCPU tiene prioridad en la sombra de STI. Para GIF=0, el argumento no es tan claro, porque la ventana donde dos NMI pueden colisionar es mucho mayor en el metal desnudo (aunque aún es pequeña). Dicho esto, KVM no debería tener un comportamiento divergente para el caso GIF=0 en función de si la compatibilidad con vNMI está habilitada o no. Y KVM ha permitido NMI simultáneas con GIF=0 durante más de una década, desde el commit 7460fb4a3400 ("KVM: Reparar NMI simultáneas"). Es decir, el manejo de GIF=0 de KVM no debe modificarse sin una *realmente* buena razón para hacerlo, y si se modifica el comportamiento de KVM, debe hacerse independientemente del soporte de vNMI.