CVE-2026-63807

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.