CVE-2026-64287 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU
flush_hyp_vcpu() copies the host vGIC state into the hyp's private vCPU on every run. The vGIC list register save and restore use used_lrs as their loop bound and expect it to stay within the number of implemented list registers. While this is generally the case, flush_hyp_vcpu() copies vgic_v3 verbatim and does not enforce this, so a value provided by the host is used at EL2 to index vgic_lr[] and access ICH_LR<n>_EL2
(host -> EL2).
Fix by clamping used_lrs to the number of implemented list registers after the copy, as the trusted path already does in vgic_flush_lr_state(). The number of implemented list registers is constant after init, so it is replicated once from kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on every entry.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists within the Linux kernel's KVM implementation for arm64 architecture, specifically affecting the virtualization subsystem's handling of virtual GIC (Generic Interrupt Controller) state management. The issue stems from improper bounds checking during the hypervisor vCPU state flushing process, creating a potential privilege escalation vector that could allow malicious guests to access unauthorized memory regions and execute arbitrary code at elevated privileges.
The technical flaw occurs in the flush_hyp_vcpu() function which copies host vGIC state into the hypervisor's private vCPU structure without proper validation of the used_lrs parameter. This parameter determines how many list registers to process during save and restore operations, but when copied verbatim from the host environment, it can contain values that exceed the actual number of implemented list registers. The vulnerability manifests when the host provides an invalid value for used_lrs that gets directly used as an index into the vgic_lr[] array at EL2 privilege level, potentially allowing out-of-bounds memory access and arbitrary code execution.
The operational impact of this vulnerability is significant within virtualized environments where untrusted guests might attempt to exploit the flaw. An attacker with control over a guest VM could manipulate the used_lrs value to bypass bounds checking and access memory locations that should remain protected from guest access. This creates a potential path for privilege escalation, allowing malicious code within the guest to execute at hypervisor level with full system privileges, compromising the integrity of the entire virtualization platform.
The fix implements proper input validation by clamping the used_lrs value to the maximum number of implemented list registers after copying from the host environment. This approach mirrors the existing trusted path validation already present in vgic_flush_lr_state() function, ensuring consistency in security controls. The solution also optimizes performance by replicating the constant number of implemented list registers once during initialization rather than reading it on every function entry, reducing unnecessary overhead while maintaining security guarantees.
This vulnerability relates to CWE-129 Input Validation and CWE-787 Out-of-bounds Write, both of which are classified under the Common Weakness Enumeration framework for software security flaws. From an ATT&CK perspective, this represents a privilege escalation technique using hypervisor-level vulnerabilities, specifically targeting the KVM hypervisor implementation through memory corruption attacks. The fix addresses these concerns by implementing proper bounds checking and validation mechanisms consistent with established security practices for virtualization environments.
The mitigation approach follows industry best practices for hypervisor security by enforcing strict parameter validation on data imported from untrusted sources while maintaining performance through optimized constant value caching. This solution prevents attackers from exploiting the discrepancy between expected and actual list register counts, ensuring that all memory accesses remain within valid bounds and protecting against potential exploitation attempts targeting the virtualization layer's integrity.