[CVE-2026-63807][MODERATE 7.0] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

[CVE-2026-63807][MODERATE 7.0] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

[AL-KERNEL]

CVE: CVE-2026-63807
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
Commit: 7b52008023b7facf40fba3ebe92449bda8ea53b9
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b52008023b7facf40fba3ebe92449bda8ea53b9
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-63807
Analysis date: Sun, 19 Jul 2026 09:30:45 -0400
ActionableScore: 5
ActionableScore lower bound: 4
Actionable bucket: Actionable Moderate at minimum
Manual review required: YES

Summary:
A local KVM user can create memslot and guest hugepage conditions that cause KVM x86 MMU hugepage recovery to read `lpage_info` out of bounds, typically crashing the host kernel, with no confirmed privilege escalation primitive but enough MMU metadata involvement to require manual review.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-63807 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-63807

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-63807	MODERATE	CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';CWE-125;CWE-129;*CWE-20;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '5.8';DESCR 'KVM x86 MMU hugepage recovery can query kvm_mmu_max_mapping_level with a shadow page gfn that is outside the target memslot. This can cause an out-of-bounds read from the memslot lpage_info array and typically results in a host page fault and kernel crash. For the CVSS the PR:L is used because reliable triggering requires a local process with access to /dev/kvm or equivalent VM control to create the VM state and memory slot conditions. The issue is not directly network reachable and is reached through KVM control plane or guest memory management interactions rather than packet traffic. Impact is at least denial of service. Because this is an out-of-bounds read in KVM MMU hugepage and rmap recovery logic, limited confidentiality or integrity impact is kept in the paranoid score for manual-review sensitivity, but HHH is not used because the patch does not show a write primitive or stale rmap UAF.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate at minimum (with actual score 5)	YES	WRITE OOB DANGER VIRT HARDWARE KPANIC MEMORY 	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=5
ActionableScoreLower=4

## 1. ActionableScore

* Conservative score: 4
* Paranoid score: 5
* Final recommended bucket: **Actionable Moderate at minimum**

## 2. Signal breakdown

Conservative signals:

* Local unprivileged trigger: +1. A local userspace VMM process with access to `/dev/kvm` can shape guest memory slots and guest mappings.
* Weak/indirect corruption candidate: +1. The bug is an unchecked GFN/memslot relationship that causes an out-of-bounds read from `slot->lpage_info`, but the patch shows read-side OOB access, not an OOB write or UAF.
* Reliable kernel crash / strong DoS: +1. The commit includes a concrete host `#PF` / Oops in `kvm_mmu_max_mapping_level()`.
* Broad/default/common subsystem exposure: +1. KVM is a broadly deployed virtualization subsystem on affected hosts.
* Privileged kernel metadata path: +1. The bug is in KVM MMU hugepage recovery and touches memslot / shadow MMU metadata.
* Legacy / non-default execution mode: -1. The affected flow is in shadow MMU / hugepage recovery rather than the most common EPT/NPT fast path.

Paranoid additional signal:

* Weak LPE concern: +1. Because this is KVM MMU code near hugepage recovery and rmap state, manual review should check whether the OOB metadata access can influence later MMU decisions. No strong write, reclaim, stale rmap UAF, or object replacement primitive is shown.

## 3. Reachability analysis

The realistic trigger is local access to KVM, normally via `/dev/kvm` from a VMM process or test harness. This is not network reachable by itself. In many deployments `/dev/kvm` is available to members of the `kvm` group, so PR:L is the practical interpretation rather than PR:H. Containers or namespaces matter only if KVM device access is delegated into them. The issue appears dependent on KVM shadow MMU hugepage recovery behavior and specific memslot / guest hugepage boundary conditions, so it is not a trivial universal trigger.

Call-site confidence: high. The provided trace and patch show the relevant call path through `kvm_mmu_recover_huge_pages()`, `kvm_set_memslot()`, and `kvm_mmu_max_mapping_level()`.

## 4. Severity interpretation

This behaves stronger than an ordinary Moderate because it is a host-kernel crash reachable from KVM control paths and involves an OOB access in MMU metadata. Realistic demonstrated impact is DoS. Theoretical escalation is not proven: the patch does not show OOB write, UAF, double free, attacker-controlled reclaim, callback control, or arbitrary memory corruption. Therefore this is best treated as Actionable Moderate, with manual review required to exclude deeper KVM MMU/rmap consequences.

## 5. One-sentence report phrase

A local KVM user can create memslot and guest hugepage conditions that cause KVM x86 MMU hugepage recovery to read `lpage_info` out of bounds, typically crashing the host kernel, with no confirmed privilege escalation primitive but enough MMU metadata involvement to require manual review.

## 6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: the demonstrated impact is host DoS, but the bug is in KVM MMU hugepage/rmap-adjacent logic and involves an out-of-bounds metadata access, so it should not be auto-closed without reviewer confirmation that no stale rmap, wrong zap, or MMU state corruption path exists.

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
Commit: 7b52008023b7facf40fba3ebe92449bda8ea53b9
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b52008023b7facf40fba3ebe92449bda8ea53b9

Commit description:

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.

Fixes: 9eba50f ("KVM: x86/mmu: Consult max mapping level when zapping collapsible SPTEs")
Cc: stable@vger.kernel.org
Cc: David Matlack <dmatlack@google.com>
Cc: James Houghton <jthoughton@google.com>
Cc: Alexander Bulekov <bkov@amazon.com>
Cc: Fred Griffoul <fgriffo@amazon.co.uk>
Cc: Alexander Graf <graf@amazon.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Filippo Sironi <sironi@amazon.de>
Cc: Ivan Orlov <iorlov@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

Changed files:
  arch/x86/kvm/mmu/mmu.c
  include/linux/kvm_host.h

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b52008023b7facf40fba3ebe92449bda8ea53b9

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-63807 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-63807

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS score: 5.8

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 4
  Paranoid ActionableScore: 5

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).