CVE-2021-46978 - The Hidden Peril in Linux Kernel’s KVM Nested Virtualization Handling
The virtualization world thrives on the seamless migration and control of virtual machines. In the heart of this magic, the Linux Kernel and its KVM (Kernel-based Virtual Machine) subsystem play a defining role—especially for nested virtualization, letting a virtual machine (VM) itself act as a hypervisor.
But like any complex software, small oversights can turn into serious bugs. CVE-2021-46978 emerged as such an issue, affecting KVM’s handling of the “enlightened VMCS” (eVMCS) on systems using nested virtualization and enabling advanced features (e.g., those required by Microsoft Hyper-V enlightenments).
Let’s break down what happened, why it matters, and how it was fixed—without drowning in jargon.
What Was the Problem?
During VM migration or saving/restoring, KVM saves *state* about nested virtualization. The expectation is that after this process, everything’s as it should be for *enlightened VMCS* (a hardware shortcut provided for Hyper-V guests).
KVM couldn’t map the eVMCS memory page immediately after migration.
- This page is identified by a GPA (guest physical address). But at the time KVM wants to restore it, the correct address might not yet be available—userspace (say, QEMU) might restore some MSRs (Model Specific Registers) in an order that means KVM only learns the eVMCS location a little too late.
The KVM core adds a request, KVM_REQ_GET_NESTED_STATE_PAGES, to handle delayed mapping
kvm_make_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu);
This flag tells KVM: “Hey, next time you get a chance, map that eVMCS page!”
But a prior fix (commit f2c7ef3ba955) introduced a subtle problem: It would clear the above request during some nested exits, which prevented eVMCS from ever being mapped in some flows.
Why is this bad?
If eVMCS is not mapped, synchronization of VMCS12 (the structure holding the nested hypervisor state) will not be reflected in eVMCS. This could cause all sorts of subtle data corruption in guest or host, unpredictable behavior, or potential privilege escalations.
The Fix: Always Map eVMCS After Migration
To resolve this, commit ac29bba76f ensures that whenever the KVM_REQ_GET_NESTED_STATE_PAGES is cleared (in nested_vmx_vmexit()), it will forcibly attempt to map the eVMCS page again:
Here’s the relevant fix in *C*
if (test_and_clear_bit(KVM_REQ_GET_NESTED_STATE_PAGES, &vcpu->requests)) {
if (vmx->nested.hv_evmcs)
nested_get_evmcs_page(vcpu);
}
Translation:
Then reattempt to grab (map) the eVMCS page right now.
Why do this hacky “band-aid?”
Because by this time, it’s really too late to signal an error up the stack. But this extra attempt prevents the worst failures and keeps things in sync.
Exploitation Impact
What could an attacker do?
Induce inconsistent VM state, causing the guest to crash.
- Possibly escalate privileges or perform arbitrary code execution if kernel memory structures are sufficiently corrupted.
- At the least, break nested virtualization for eVMCS-enabled guests (e.g., running Hyper-V in KVM on Azure/Cloud).
Is it remotely exploitable?
Not directly. It requires a malicious or buggy userspace (like QEMU) or a carefully crafted guest to trigger this with advanced state manipulation/migration.
But if you run nested virtualization in production (especially with cloud providers, or for security research), this bug is serious.
Links & References
- Linux Kernel Commit ac29bba76f7b921e19fc4e65ef4b9a528d7e3b (the fix)
- Original CVE entry (NVD)
- KVM documentation
- QEMU Migration internals
- Microsoft eVMCS reference
TL;DR
CVE-2021-46978 was a subtle but serious bug in Linux’s KVM:
After a VM migration, on nested VM exit, the eVMCS page for Hyper-V enlightenment might not get mapped—leaving virtualization state unsynchronized and security potentially at risk.
Patch your Linux kernels! Especially if you use nested virtualization features with Hyper-V guests.
*This article was written exclusively in clear American English, summarizing the issue at a level suitable for infrastructure and security professionals alike. If you operate virtualized environments, always stay alert for these “hidden gems”—they could be the difference between a fast migration and a costly security incident.*
Timeline
Published on: 02/28/2024 09:15:37 UTC
Last modified on: 11/04/2024 18:35:00 UTC