CVE-2026-63807: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-63807 Overview

CVE-2026-63807 is an out-of-bounds read vulnerability in the Linux kernel's Kernel-based Virtual Machine (KVM) subsystem, specifically in the x86 shadow Memory Management Unit (MMU). The flaw resides in the hugepage recovery code path, where KVM fails to verify that a shadow page's base guest frame number (gfn) is contained within the target memory slot before querying the maximum mapping level. A malicious guest can trigger an out-of-bounds access to the memslot's lpage_info array, resulting in a host kernel page fault and denial of service.

Critical Impact
A local unprivileged user or guest VM can crash the host kernel by triggering an out-of-bounds read in kvm_mmu_max_mapping_level, impacting host availability and multi-tenant isolation.

Affected Products

Linux kernel versions containing the KVM x86 shadow MMU hugepage recovery logic
Systems running KVM-based virtualization on x86 hosts
Distributions shipping affected upstream kernels prior to the referenced stable commits

Discovery Timeline

2026-07-19 - CVE-2026-63807 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63807

Vulnerability Analysis

The vulnerability occurs in the KVM shadow MMU hugepage recovery flow. When KVM faults in guest memory and the guest's mapping size exceeds KVM's current maximum mapping level, KVM creates a direct shadow page. The target gfn for a direct shadow page is derived from the base gfn of the shadow page itself. During dirty logging, KVM temporarily forces 4KiB mappings, and the recovery path later attempts to promote these back to hugepages.

If a guest creates a hugepage mapping in its page tables that extends below the bounds of a host memslot, KVM may link a direct shadow page whose gfn falls outside the memslot. The leaf mapping and rmap entry remain in-bounds, but the parent shadow page's gfn does not. When kvm_mmu_recover_huge_pages subsequently calls kvm_mmu_max_mapping_level with the out-of-bounds gfn, the function performs a lookup into the vmalloc-backed lpage_info array, triggering a host-side page fault.

Root Cause

The root cause is missing bounds validation in the hugepage recovery path. The code queries the maximum mapping level using a shadow page's gfn without first confirming that the gfn lies within the target memslot. Because lpage_info is sized to the memslot and allocated via vmalloc, an out-of-bounds index dereferences unmapped kernel virtual memory and produces a supervisor-mode #PF.

Attack Vector

Exploitation requires local access with the ability to run a guest VM on the host. A guest constructs page table entries that create a hugepage mapping crossing the lower boundary of a host memslot. Combined with dirty logging transitions that drive the hugepage recovery path, this causes KVM to dereference lpage_info outside its valid range. The observed crash signature is a kernel Oops in kvm_mmu_max_mapping_level+0x79/0x2b0 reached from kvm_mmu_recover_huge_pages via kvm_set_memslot and kvm_vm_ioctl.

No verified public exploitation code is available. The vulnerability behavior is documented in the upstream commit messages linked in the references section.

Detection Methods for CVE-2026-63807

Indicators of Compromise

Host kernel Oops messages referencing kvm_mmu_max_mapping_level in the call trace
Page fault entries similar to BUG: unable to handle page fault for address: ffffc9xxxxxxxxxx originating from KVM modules
Unexpected host crashes or VM termination correlated with guest memslot resizing or dirty logging operations

Detection Strategies

Monitor dmesg and /var/log/kern.log for KVM-related kernel panics and stack traces that include kvm_mmu_recover_huge_pages or kvm_mmu_max_mapping_level.
Audit running kernel versions across virtualization hosts and compare against the patched stable commits listed in the references.
Track guest KVM_SET_USER_MEMORY_REGION ioctl activity that coincides with host instability.

Monitoring Recommendations

Enable kernel crash dump collection (kdump) on KVM hosts to capture full context of any #PF in KVM code paths.
Aggregate host kernel logs centrally and alert on stack traces containing KVM MMU symbols.
Baseline expected memslot and dirty logging operations per hypervisor to detect anomalous guest-driven patterns.

How to Mitigate CVE-2026-63807

Immediate Actions Required

Inventory all KVM hypervisor hosts and identify kernel versions that predate the fix commits.
Apply distribution kernel updates that incorporate the upstream fix as soon as they are available.
Restrict local access to hypervisor hosts and limit which users may create or manage guest VMs.

Patch Information

The fix ensures the base gfn of a shadow page is contained within the target memslot before kvm_mmu_max_mapping_level is called during hugepage recovery. Backports are available in the upstream stable tree via the following commits: Linux Kernel Commit 18587f, Linux Kernel Commit 48b91e, Linux Kernel Commit 5cab1c, Linux Kernel Commit 7b5200, Linux Kernel Commit b2ae32, Linux Kernel Commit c5c29b, and Linux Kernel Commit ef057c.

Workarounds

Where patching is not immediately feasible, avoid dynamic guest memslot layouts that permit guest hugepage mappings to extend below memslot boundaries.
Consider disabling KVM dirty logging features on affected hosts until the patched kernel is deployed, since the recovery path is exercised during dirty logging transitions.
Reboot hypervisor hosts into a patched kernel image once vendor updates are installed to ensure the fix is active.

bash

# Verify running kernel version and reboot into patched kernel
uname -r
sudo apt list --installed 2>/dev/null | grep linux-image
sudo dnf list installed kernel 2>/dev/null
# After installing a patched kernel package:
sudo reboot