CVE-2026-63807
published 2026-07-19CVE-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…
PriorityP345high8.8CVSS 3.1
AVLACLPRLUINSCCHIHAH
EPSS
0.13%
3.0th percentile
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 + IC
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| linux | linux | — | — |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < 7b52008023b7facf40fba3ebe92449bda8ea53b9 | 7b52008023b7facf40fba3ebe92449bda8ea53b9 |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < 5cab1c989f938f5e1b9a0de66486f1fc2c28479b | 5cab1c989f938f5e1b9a0de66486f1fc2c28479b |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < 48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8 | 48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8 |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < c5c29b3c268332afe67d598a034c58344540ed92 | c5c29b3c268332afe67d598a034c58344540ed92 |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < 18587f9831612e24cd8f24be1ec15478feff7abc | 18587f9831612e24cd8f24be1ec15478feff7abc |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < b2ae3245ea44dccaa9af676b6747476951883318 | b2ae3245ea44dccaa9af676b6747476951883318 |
| linux | linux | >= 9eba50f8d7fcb61774f160890f98239fa3ab68a6 < ef057cbf825e03b63f6edf5980f96abf3c53089d | ef057cbf825e03b63f6edf5980f96abf3c53089d |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 5.12 < 5.15.211 | 5.15.211 |
| linux | linux_kernel | >= 5.16 < 6.1.177 | 6.1.177 |
| linux | linux_kernel | >= 6.13 < 6.18.38 | 6.18.38 |
| linux | linux_kernel | >= 6.19 < 7.1.3 | 7.1.3 |
| linux | linux_kernel | >= 6.2 < 6.6.144 | 6.6.144 |
| linux | linux_kernel | >= 6.7 < 6.12.95 | 6.12.95 |
CVSS provenance
nvdv3.18.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vendor_redhat8.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
vendor_redhat·2026-07-19·CVSS 8.8
CVE-2026-63807 [HIGH] CWE-125 kernel: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
kernel: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
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
gr
GHSA
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
ghsa_unreviewed·2026-07-19
CVE-2026-63807 [HIGH] 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
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
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/18587f9831612e24cd8f24be1ec15478feff7abchttps://git.kernel.org/stable/c/48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8https://git.kernel.org/stable/c/5cab1c989f938f5e1b9a0de66486f1fc2c28479bhttps://git.kernel.org/stable/c/7b52008023b7facf40fba3ebe92449bda8ea53b9https://git.kernel.org/stable/c/b2ae3245ea44dccaa9af676b6747476951883318https://git.kernel.org/stable/c/c5c29b3c268332afe67d598a034c58344540ed92https://git.kernel.org/stable/c/ef057cbf825e03b63f6edf5980f96abf3c53089d
2026-07-19
Published