2.3 KiB
CVE-2024-39483
Description
In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright maskedWhen requesting an NMI window, WARN on vNMI support being enabled if andonly if NMIs are actually masked, i.e. if the vCPU is already handling anNMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point ofview) is to inject one NMI and pend the other. When using vNMI, KVM pendsthe second NMI simply by setting V_NMI_PENDING, and lets the CPU do therest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).However, if KVM can't immediately inject an NMI, e.g. because the vCPU isin an STI shadow or is running with GIF=0, then KVM will request an NMIwindow and trigger the WARN (but still function correctly).Whether or not the GIF=0 case makes sense is debatable, as the intent ofKVM's behavior is to provide functionality that is as close to realhardware as possible. E.g. if two NMIs are sent in quick succession, theprobability of both NMIs arriving in an STI shadow is infinitesimally lowon real hardware, but significantly larger in a virtual environment, e.g.if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn'tas clear cut, because the window where two NMIs can collide is much largerin bare metal (though still small).That said, KVM should not have divergent behavior for the GIF=0 case basedon whether or not vNMI support is enabled. And KVM has allowedsimultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't bemodified without a really good reason to do so, and if KVM's behaviorwere to be modified, it should be done irrespective of vNMI support.
POC
Reference
No PoCs from references.