CVE-2021-47277: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas. Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.
AI Analysis
Technical Summary
CVE-2021-47277 is a vulnerability in the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem related to speculative execution attacks. KVM translates guest physical addresses (gpa) to host virtual addresses (hva) using memory slots (memslots). The translation function __gfn_to_hva_memslot calculates the host virtual address by offsetting from a base address using the guest frame number (gfn). Normally, the gfn is checked to ensure it falls within the guest's physical memory boundaries. However, due to speculative execution, the CPU may bypass this boundary check temporarily and proceed with an out-of-bounds gfn, leading to an out-of-bounds host virtual address calculation. This speculative execution can be exploited as a Spectre-style gadget, where two consecutive reads occur with the second dependent on the first, potentially leaking sensitive data from the host or other guests. Although the exploitability is not fully confirmed, the vulnerability is significant because it could allow a malicious guest VM to read data from the host or other VMs by abusing speculative execution. The patch for this vulnerability proactively masks out-of-bounds gfns to prevent speculative execution from accessing invalid host addresses. Architectures like ARM, which use address masking instead of LFENCE barriers, are more susceptible, while x86 is currently protected by LFENCE barriers in get_user(), but future changes might increase risk. The vulnerability does not cover all KVM guest memory access functions, but the uncovered functions are limited in scope and unlikely to be useful for chaining speculative reads. No known exploits are reported in the wild as of the publication date.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to environments using Linux KVM virtualization, which is common in cloud infrastructure, data centers, and enterprise virtualization setups. Exploitation could lead to unauthorized data disclosure between guest VMs and the host, undermining confidentiality and potentially integrity if speculative execution side channels are chained with other vulnerabilities. This risk is heightened in multi-tenant cloud environments where isolation between customers' VMs is critical. The speculative execution nature of the vulnerability makes it difficult to detect and mitigate without patches. Organizations relying on Linux KVM for critical workloads, especially those handling sensitive or regulated data (e.g., financial, healthcare, government sectors), could face compliance and reputational risks if this vulnerability is exploited. Although no active exploits are known, the potential for future exploitation exists, particularly as speculative execution attacks have been a persistent class of vulnerabilities. The impact on availability is minimal, but confidentiality breaches could have severe consequences.
Mitigation Recommendations
European organizations should prioritize applying the Linux kernel patches that mask out-of-bounds gfns in the KVM subsystem to prevent speculative execution attacks. Specifically, ensure that all Linux hosts running KVM are updated to kernel versions including the fix for CVE-2021-47277. For environments using ARM architectures, where address masking is already in place, verify that the latest mitigations are applied. Monitor kernel updates closely for any additional patches related to speculative execution in KVM, especially changes to x86 uaccess.h that might affect LFENCE barriers. Implement strict VM isolation policies and minimize the attack surface by limiting guest VM privileges and access to host resources. Employ runtime monitoring tools that can detect abnormal speculative execution patterns or side-channel attack indicators. Additionally, consider using hardware and firmware updates that provide speculative execution mitigations (e.g., Intel and AMD microcode updates). Regularly audit virtualization configurations and restrict access to hypervisor management interfaces to reduce risk of exploitation. Finally, maintain an incident response plan tailored for side-channel and speculative execution vulnerabilities.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Ireland, Italy
CVE-2021-47277: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas. Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.
AI-Powered Analysis
Technical Analysis
CVE-2021-47277 is a vulnerability in the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem related to speculative execution attacks. KVM translates guest physical addresses (gpa) to host virtual addresses (hva) using memory slots (memslots). The translation function __gfn_to_hva_memslot calculates the host virtual address by offsetting from a base address using the guest frame number (gfn). Normally, the gfn is checked to ensure it falls within the guest's physical memory boundaries. However, due to speculative execution, the CPU may bypass this boundary check temporarily and proceed with an out-of-bounds gfn, leading to an out-of-bounds host virtual address calculation. This speculative execution can be exploited as a Spectre-style gadget, where two consecutive reads occur with the second dependent on the first, potentially leaking sensitive data from the host or other guests. Although the exploitability is not fully confirmed, the vulnerability is significant because it could allow a malicious guest VM to read data from the host or other VMs by abusing speculative execution. The patch for this vulnerability proactively masks out-of-bounds gfns to prevent speculative execution from accessing invalid host addresses. Architectures like ARM, which use address masking instead of LFENCE barriers, are more susceptible, while x86 is currently protected by LFENCE barriers in get_user(), but future changes might increase risk. The vulnerability does not cover all KVM guest memory access functions, but the uncovered functions are limited in scope and unlikely to be useful for chaining speculative reads. No known exploits are reported in the wild as of the publication date.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to environments using Linux KVM virtualization, which is common in cloud infrastructure, data centers, and enterprise virtualization setups. Exploitation could lead to unauthorized data disclosure between guest VMs and the host, undermining confidentiality and potentially integrity if speculative execution side channels are chained with other vulnerabilities. This risk is heightened in multi-tenant cloud environments where isolation between customers' VMs is critical. The speculative execution nature of the vulnerability makes it difficult to detect and mitigate without patches. Organizations relying on Linux KVM for critical workloads, especially those handling sensitive or regulated data (e.g., financial, healthcare, government sectors), could face compliance and reputational risks if this vulnerability is exploited. Although no active exploits are known, the potential for future exploitation exists, particularly as speculative execution attacks have been a persistent class of vulnerabilities. The impact on availability is minimal, but confidentiality breaches could have severe consequences.
Mitigation Recommendations
European organizations should prioritize applying the Linux kernel patches that mask out-of-bounds gfns in the KVM subsystem to prevent speculative execution attacks. Specifically, ensure that all Linux hosts running KVM are updated to kernel versions including the fix for CVE-2021-47277. For environments using ARM architectures, where address masking is already in place, verify that the latest mitigations are applied. Monitor kernel updates closely for any additional patches related to speculative execution in KVM, especially changes to x86 uaccess.h that might affect LFENCE barriers. Implement strict VM isolation policies and minimize the attack surface by limiting guest VM privileges and access to host resources. Employ runtime monitoring tools that can detect abnormal speculative execution patterns or side-channel attack indicators. Additionally, consider using hardware and firmware updates that provide speculative execution mitigations (e.g., Intel and AMD microcode updates). Regularly audit virtualization configurations and restrict access to hypervisor management interfaces to reduce risk of exploitation. Finally, maintain an incident response plan tailored for side-channel and speculative execution vulnerabilities.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-05-21T13:27:52.128Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9835c4522896dcbea2ab
Added to database: 5/21/2025, 9:09:09 AM
Last enriched: 6/26/2025, 11:24:32 AM
Last updated: 7/31/2025, 2:01:46 PM
Views: 12
Related Threats
Researcher to release exploit for full auth bypass on FortiWeb
HighCVE-2025-9091: Hard-coded Credentials in Tenda AC20
LowCVE-2025-9090: Command Injection in Tenda AC20
MediumCVE-2025-9092: CWE-400 Uncontrolled Resource Consumption in Legion of the Bouncy Castle Inc. Bouncy Castle for Java - BC-FJA 2.1.0
LowCVE-2025-9089: Stack-based Buffer Overflow in Tenda AC20
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.