From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-63807][MODERATE 7.0] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level Date: Sun, 19 Jul 2026 09:30:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-63807 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: 4 X-AL-KERNEL-Commit: 7b52008023b7facf40fba3ebe92449bda8ea53b9 List-Id: 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: 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 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 Cc: James Houghton Cc: Alexander Bulekov Cc: Fred Griffoul Cc: Alexander Graf Cc: David Woodhouse Cc: Filippo Sironi Cc: Ivan Orlov Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin 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).