CVE-2024-39483

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked<br /> <br /> When requesting an NMI window, WARN on vNMI support being enabled if and<br /> only if NMIs are actually masked, i.e. if the vCPU is already handling an<br /> NMI. KVM&amp;#39;s ABI for NMIs that arrive simultanesouly (from KVM&amp;#39;s point of<br /> view) is to inject one NMI and pend the other. When using vNMI, KVM pends<br /> the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the<br /> rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).<br /> <br /> However, if KVM can&amp;#39;t immediately inject an NMI, e.g. because the vCPU is<br /> in an STI shadow or is running with GIF=0, then KVM will request an NMI<br /> window and trigger the WARN (but still function correctly).<br /> <br /> Whether or not the GIF=0 case makes sense is debatable, as the intent of<br /> KVM&amp;#39;s behavior is to provide functionality that is as close to real<br /> hardware as possible. E.g. if two NMIs are sent in quick succession, the<br /> probability of both NMIs arriving in an STI shadow is infinitesimally low<br /> on real hardware, but significantly larger in a virtual environment, e.g.<br /> if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn&amp;#39;t<br /> as clear cut, because the window where two NMIs can collide is much larger<br /> in bare metal (though still small).<br /> <br /> That said, KVM should not have divergent behavior for the GIF=0 case based<br /> on whether or not vNMI support is enabled. And KVM has allowed<br /> simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400<br /> ("KVM: Fix simultaneous NMIs"). I.e. KVM&amp;#39;s GIF=0 handling shouldn&amp;#39;t be<br /> modified without a *really* good reason to do so, and if KVM&amp;#39;s behavior<br /> were to be modified, it should be done irrespective of vNMI support.