CVE-2026-63807 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot.
When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage.
But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds.
BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP
CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]
Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]
kvm_set_memslot+0x1ee/0x590 [kvm]
kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]
kvm_vm_ioctl+0x9bf/0x15d0 [kvm]
__x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK>
Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's KVM virtualization subsystem, specifically in the x86 memory management unit implementation. The issue manifests during hugepage recovery operations in the shadow MMU where the system fails to properly validate that the base guest frame number (gfn) of a shadow page falls within the boundaries of the target memory slot before examining the maximum mapping level. This flaw creates a potential out-of-bounds memory access scenario that can result in kernel page faults and system instability.
The technical root cause stems from the order of operations during memory fault handling when KVM attempts to recover hugepages in the shadow MMU. When processing guest memory mappings that exceed KVM's current maximum mapping size, the system creates direct shadow pages without intermediate guest page table entries. During this process, if a guest creates a hugepage mapping that extends beyond the bounds of a memslot, KVM links a direct shadow page with a gfn that lies outside the valid memslot boundaries. The rmap entry for the leaf mapping remains correctly bounded, but the parent shadow page's gfn becomes invalid, leading to memory access violations.
The operational impact of this vulnerability is significant as it can cause kernel panics and system crashes through supervisor read access faults in kernel mode. The error pattern typically manifests as a page fault when attempting to access memory at addresses like ffffc90000806ffc with error code 0x0000 indicating a not-present page condition. This vulnerability affects systems running Linux kernels with KVM virtualization enabled and can be exploited through malicious guest VM configurations that manipulate memory mappings beyond memslot boundaries.
The fix implemented resolves the vulnerability by removing pre-checks for hugepage bounds validation during the recovery process, recognizing that the existing checks performed by kvm_mmu_max_mapping_level() already provide sufficient boundary protection. This approach avoids a potentially unnecessary micro-optimization while ensuring proper memory access validation. The solution aligns with CWE-129 input validation and CWE-787 out-of-bounds write patterns commonly seen in virtualization security contexts. From an ATT&CK perspective, this vulnerability relates to privilege escalation through kernel exploitation techniques and could be leveraged for system compromise in virtualized environments.
Security practitioners should ensure their systems are updated with patches addressing this vulnerability, particularly in environments running KVM-based virtualization where guests may have elevated privileges or where memory mapping behaviors might be manipulated. The fix represents a defensive programming approach that prioritizes correctness over potential performance optimizations in critical kernel subsystems. This vulnerability demonstrates the complexity of memory management in virtualized environments and the importance of proper boundary validation in kernel space operations, especially when dealing with complex translation scenarios involving hugepage mappings across multiple memory regions.