CVE-2026-63807

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level<br /> <br /> When recovering hugepages in the shadow MMU, verify that the base gfn of<br /> the shadow page is actually contained within the target memslot, *before*<br /> querying the max mapping level given the shadow page&amp;#39;s gfn. Failure to<br /> pre-check the validity of the gfn can lead to an out-of-bounds access to<br /> the slot&amp;#39;s lpage_info (which typically manifests as a host #PF because the<br /> lpage_info is vmalloc&amp;#39;d) if the guest creates a hugepage mapping (in its<br /> PTEs) that extends "below" the bounds of a memslot.<br /> <br /> When faulting in memory for a guest, and the size of the guest mapping is<br /> greater than KVM&amp;#39;s (current) max mapping, then KVM will create a "direct"<br /> shadow page (direct in that there are no gPTEs to shadow, and so the target<br /> gfn is a direct calculation given the base gfn of the shadow page). The<br /> hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB<br /> mappings when dirty logging generates the guest &gt; host mapping size case.<br /> When the 4KiB restriction is lifted, then KVM can replace the shadow page<br /> with a hugepage.<br /> <br /> But if KVM originally used a smaller mapping than the guest because the<br /> range of memory covered by the guest hugepage exceeds the bounds of a<br /> memslot, then KVM will link a direct shadow page with a gfn that is outside<br /> the bounds of the memslot being used to fault in memory. The rmap entry<br /> added for the leaf mapping is correct and within bounds, but the gfn of the<br /> leaf SPTE&amp;#39;s parent shadow page will be out of bounds.<br /> <br /> BUG: unable to handle page fault for address: ffffc90000806ffc<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0<br /> Oops: Oops: 0000 [#1] SMP<br /> 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<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]<br /> Call Trace:<br /> <br /> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]<br /> kvm_set_memslot+0x1ee/0x590 [kvm]<br /> kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]<br /> kvm_vm_ioctl+0x9bf/0x15d0 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0xb7/0xbb0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f21c0f1a9bf<br /> <br /> <br /> Don&amp;#39;t bother pre-checking the bounds of the potential hugepage, i.e. don&amp;#39;t<br /> check that e.g. sp-&gt;gfn + KVM_PAGES_PER_HPAGE(sp-&gt;role.level + 1) is also<br /> within the memslot, as the checks performed by kvm_mmu_max_mapping_level()<br /> are a superset of the basic bounds checks. I.e. pre-checking the full<br /> range would be a dubious micro-optimization.