CVE-2024-39483: KVM: SVM: Resolved Vulnerability Warns on vNMI + NMI Window if NMIs are Outright Masked

In a recent vulnerability patch in the Linux kernel, a warning triggering issue has been addressed. The vulnerability CVE-2024-39483 specifically involves the KVM: SVM component. This blog post dives into the technical details of the vulnerability, its potential implications, and how it has been resolved.

Details

The vulnerability revolves around KVM's handling of Non-Maskable Interrupts (NMIs) and specifically when requesting an NMI window. It has been discovered that the kernel can potentially warn on vNMI support being enabled if and only if NMIs are actually masked, i.e., if the vCPU is already handling an NMI.

KVM's Application Binary Interface (ABI) for NMIs that arrive simultaneously (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI by simply setting the V_NMI_PENDING flag and lets the CPU handle the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).

However, if KVM is unable to immediately inject an NMI due to the vCPU being in an STI shadow, or the vCPU is running with GIF=, then KVM will request an NMI window and trigger a warning, although it would still function correctly.

This code snippet demonstrates the scenario where the warning is triggered

if (kvm_guest_has_nested_events(vcpu) &&
     (svm->vmcb01.interrupt_shadow || svm->vcpu.arch.nmi_injected)) {
	WARN_ON_ONCE(!(svm->vcpu.arch.nmi_pending));
	svm->vcpu.arch.nmi_pending = true;
	return;
}

Read the original discussion and patch details here: https://lkml.org/lkml/2022/2/2/749

Possible implications

There is a potential inconsistency in how KVM handles the GIF= case, as KVM's behavior should not diverge based on whether vNMI support is enabled. This warning might indicate an underlying bug that might lead to undefined behavior or incorrect results in specific configurations or usage scenarios.

Resolution

Having simultaneous NMIs with GIF= for over a decade, this particular caveat is deemed to not require any immediate changes in KVM's behavior. Instead, the current resolution is limited to merely addressing the WARN triggering issue while still ensuring functionality is maintained.

In conclusion, this vulnerability has been addressed in the Linux kernel, ensuring that the warning no longer triggers during specific circumstances in the KVM: SVM component. Although the potential implications are not expected to result in critical issues, it is crucial for developers and maintainers to be aware of these findings and ensure that similar vulnerabilities are minimized in future iterations of the software.

Timeline

Published on: 07/05/2024 07:15:10 UTC
Last modified on: 07/15/2024 06:50:19 UTC