CVE-2026-63807: Update Linux KVM Hosts to Prevent Crashes

CVE-2026-63807 is a Linux KVM x86 flaw in the shadow-MMU hugepage recovery path that can crash the host when a guest’s page-table layout crosses the lower boundary of a KVM memory slot. It affects the Linux kernel that runs KVM, not Windows itself: Windows, Linux, and appliance guests do not receive a guest-OS patch for this issue. The required mitigation is to update the Linux KVM host to a vendor package containing the fix, reboot it, and verify that the updated kernel is the one actually running.
The supplied record documents a guest-influenced out-of-bounds access that typically manifests as a host page fault. NVD has not assigned CVSS scoring and does not confirm VM escape or guest-to-host code execution. That makes this an availability and host-reliability issue with a clear patching action, not evidence for broader claims about confirmed exploitation outcomes.

Verify the host kernel first​

NVD identifies Linux 5.12 as affected and lists fixed or unaffected points in several stable kernel series:

Linux stable series	NVD-listed unaffected/fixed stable-series point	What that means operationally
5.15.x	5.15.211	Update to this upstream stable level or to a vendor package documented as containing the equivalent backport.
6.1.x	6.1.177	Confirm the running host kernel includes the fix, whether through this point or a vendor backport.
6.6.x	6.6.144	Treat this as an upstream stable-series reference, not a universal package version.
6.12.x	6.12.95	Use this upstream point or a distribution kernel with a documented equivalent fix.
6.18.x	6.18.38	Verify that the installed and running vendor kernel contains the remediation.

These values are NVD-listed unaffected or fixed stable-series points. They are not guaranteed package versions for every Linux distribution. Enterprise distributions, virtualization appliances, and cloud images frequently retain a familiar base-version string while backporting security and reliability fixes. A host can therefore be protected with a version string that appears older than an upstream fixed point, but only when the vendor changelog, advisory, or source-package history confirms the backport.
Use the following procedure on every Linux host that provides x86 KVM virtualization:

1. Identify the running kernel:
   uname -r
2. Identify the package that owns the running kernel image. The following are distribution-specific examples; use the command appropriate for the host’s package system.
   Debian and Ubuntu example:
   dpkg -S "/boot/vmlinuz-$(uname -r)"
   RPM-based distribution example:
   rpm -qf "/boot/vmlinuz-$(uname -r)"
   If the boot-image path differs on the system, query the installed kernel packages and match them to the output of uname -r.
3. Check the owning package’s vendor changelog, security advisory, or update notes for CVE-2026-63807. Where a vendor references upstream stable fixes rather than CVE identifiers, compare its documented fix against the applicable NVD-listed stable-series point: 5.15.211, 6.1.177, 6.6.144, 6.12.95, or 6.18.38.
4. Install the vendor’s updated kernel package through the normal, supported update mechanism. Do not assume that updating QEMU userspace alone addresses a KVM kernel defect.
5. Reboot the host. The patched KVM code is in the kernel, so an installed update is not sufficient until the machine has booted into it.
6. After rebooting, run:
   uname -r
   Confirm that the displayed kernel is the intended updated build, then repeat the package and advisory check if the distribution uses backported fixes.

For hosts built from self-maintained kernels, compare the kernel source and stable backport history against the applicable upstream fixed point. NVD’s affected-version data includes multiple Git ranges beginning at baseline commit 9eba50f8d7fcb61774f160890f98239fa3ab68a6 and ending before stable fix endpoints. That detail is primarily relevant to kernel builders, appliance vendors, and teams maintaining custom forks; most administrators should use their vendor’s supported kernel update path.

---

The bug sits in KVM’s shadow-MMU hugepage handling​

The CVE’s formal title — “KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level” — describes the fix more directly than it may initially appear. According to the NVD record sourced from kernel.org, the vulnerable logic is in KVM’s x86 memory-management code, including arch/x86/kvm/mmu/mmu.c and include/linux/kvm_host.h. It involves the shadow MMU, KVM’s host-side machinery for representing and managing guest page-table state.
The documented boundary condition occurs when a guest hugepage mapping extends below the bounds of a KVM memory slot. KVM can have a valid leaf mapping within the slot while a related parent shadow page carries a base guest frame number outside the slot being evaluated.
That distinction matters because KVM maintains slot-local metadata for large-page handling. If code consults the maximum mapping level using an out-of-range base guest frame number before confirming that the value belongs to the relevant memory slot, it can access beyond the slot’s lpage_info allocation.
The supplied advisory describes the observed result plainly: the out-of-bounds access “typically manifests as a host #PF because the lpage_info is vmalloc’d.” In practical terms, the documented manifestation is a host-kernel page fault. The failure is in the Linux virtualization host’s kernel memory-management path, rather than a Windows guest blue screen, an application failure inside a guest, or a QEMU userspace parsing issue.

A validation-order fix closes the unsafe path​

The upstream remediation is a focused ordering correction: KVM verifies that the shadow page’s base guest frame number belongs to the target memory slot before asking what mapping size is allowed.
That is the security-relevant rule. The maximum-mapping-level helper has useful range checks, but it must not be asked to inspect slot-specific large-page metadata using a base value that has not first been validated for the slot under consideration. The fix ensures that the helper receives a guest frame number that is appropriate for the memslot it is about to inspect.
The advisory also explains why the patch does not add a broader preliminary check for every page in a potential hugepage range. The existing mapping-level helper’s checks cover the needed range behavior once the base guest frame number has been established as belonging to the intended slot. The correction is therefore not a redesign of hugepage support; it is a targeted fix for an unsafe validation order.
This distinction helps explain why the issue should be patched even though it is narrow. The vulnerability is not a general statement that hugepages are unsafe, nor does it establish that ordinary guest activity will produce a host failure. It identifies a specific out-of-bounds access in a KVM x86 shadow-MMU boundary case and supplies stable-series remediation points for it.

What the available crash evidence establishes​

The supplied crash evidence shows that the issue was reproduced with mmu_stress_test on CPU 13 under a QEMU Standard PC configuration. The host reported a supervisor-mode page fault at ffffc90000806ffc, and the failure occurred in kvm_mmu_max_mapping_level.
That is useful operational evidence because it places the fault in host-side KVM memory-management code. The crash information also includes a kernel build identified as 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm. Administrators should not treat that build string as the only affected kernel. The relevant question is whether the exact kernel running on a host contains the remediation, either through the applicable upstream stable release or a documented vendor backport.
NVD currently provides no CVSS v4 assessment and no CVSS v3.x or v2 score for this CVE. It also does not provide a confirmed severity rating, weakness classification, VM escape finding, or code-execution finding. The supported conclusion is narrower: the record describes a guest-influenced out-of-bounds access in KVM’s x86 shadow-MMU handling that typically presents as a host page fault.

Timeline​

• Upstream remediation: The supplied material identifies stable-series fixed points but does not provide an upstream commit date.
• NVD record status: The supplied material identifies NVD affected-version information and fixed stable-series points, but no verified publication or modification dates are included here.
• Administrative milestone: A host is remediated only after the vendor update is installed, the system is rebooted, and uname -r confirms that the updated kernel is running.

---

Stable backports are useful, but package verification is essential​

NVD’s stable-series information gives operators a practical starting point. Linux 5.12 is listed as affected, while versions before 5.12 are listed as unaffected. The listed 5.15.x, 6.1.x, 6.6.x, 6.12.x, and 6.18.x points show where the fix is represented in upstream stable maintenance.
That does not remove the need to check distribution packaging. Kernel vendors routinely backport fixes into supported builds without adopting every newer upstream version number. Conversely, a custom build may report a newer-looking release family but omit a specific stable backport. Kernel release strings alone are useful inventory data, not complete proof of remediation.
The defensible verification sequence is therefore:

• Record the running kernel with uname -r.
• Identify its owning package.
• Review the vendor’s changelog, advisory, or errata entry for CVE-2026-63807 or the equivalent upstream remediation.
• Install the supported update.
• Reboot the KVM host.
• Run uname -r again and confirm the expected updated kernel is active.

This is especially important on systems where maintenance teams update packages during a standard patch window but defer reboots. A patched kernel package sitting on disk does not protect a host that is still running its previous kernel image.

Dirty logging and memslot operations are investigation priorities, not proven exposure ratings​

The supplied material supports a 4KiB-versus-hugepage boundary condition in KVM’s hugepage recovery handling. It also identifies a memory-slot boundary as central to the flaw. Those facts can help platform teams decide what to examine while scheduling maintenance.
They should not be expanded into unsupported operational claims. The available record does not establish that dirty logging routinely triggers this flaw in production, that specific migration or backup workflows are common causes, or that memory-slot changes and dynamic VM memory reconfiguration increase the likelihood of impact. Those activities may be reasonable investigation priorities for KVM operators who are reviewing host configuration and workloads, but they are not demonstrated exposure conditions in the supplied record.
For incident review, teams may still preserve host crash logs that reference kvm_mmu_max_mapping_level, along with the running kernel version, installed kernel package, QEMU version, host configuration, and guest workload context. That information can help distinguish this issue from unrelated host failures and can support vendor escalation where needed. It should not be used to infer a confirmed call chain or broader exploit scenario that the available evidence does not establish.

Action checklist for admins​

• Inventory Linux systems that run x86 KVM workloads, including QEMU-based labs, test nodes, appliances, and production virtualization hosts.
• On each host, run uname -r and record the running kernel version.
• Identify the package that owns the running kernel image using the host’s distribution package manager.
• Compare the vendor package changelog, advisory, or errata information against CVE-2026-63807 or the applicable upstream fixed point.
• Treat 5.15.211, 6.1.177, 6.6.144, 6.12.95, and 6.18.38 as NVD-listed upstream stable-series references, not mandatory package-version strings.
• Install the vendor kernel update that contains the fix or an equivalent documented backport.
• Reboot the host so that the updated kernel and KVM code are loaded.
• Run uname -r after reboot and confirm that the new kernel is actually running.
• Review dirty-logging and memslot-related configurations as possible investigation priorities if the environment is being assessed for relevant KVM behavior, without treating them as established risk multipliers.
• Preserve relevant host logs while remediation is underway, especially if they identify KVM x86 MMU code.

---

The details worth carrying into the change window​

CVE-2026-63807 is a narrowly defined KVM issue, but its operational lesson is straightforward: host-side virtualization code must validate memory-slot context before consulting metadata that is specific to that slot. In this case, an out-of-range parent shadow-page guest frame number could lead KVM’s hugepage recovery handling to access large-page tracking data out of bounds.
The strongest facts for administrators are these:

• The affected component is Linux KVM’s x86 shadow MMU, not Windows itself.
• The documented condition involves hugepage recovery and a guest mapping that extends below a KVM memory-slot boundary.
• The documented manifestation is an out-of-bounds access that typically results in a host kernel page fault.
• Linux 5.12 is listed as affected, and NVD lists fixed or unaffected stable-series points for 5.15.x, 6.1.x, 6.6.x, 6.12.x, and 6.18.x.
• The values 5.15.211, 6.1.177, 6.6.144, 6.12.95, and 6.18.38 are upstream stable-series references, not guaranteed distribution package versions.
• NVD has not assigned CVSS scoring or confirmed VM escape or code execution.
• Windows guests are not patched for this issue; the Linux KVM host kernel must be updated and rebooted.

CVE-2026-63807 is not a reason to abandon KVM or hugepage support. It is a reason to keep host-kernel maintenance tied to verification rather than assumptions. The reliable closeout is simple: identify the running kernel, confirm the vendor fix or applicable upstream stable point, install the supported update, reboot the host, and verify with uname -r that the remediated kernel is now in service.

---

References​

1. Primary source: NVD / Linux Kernel
   Published: 2026-07-20T01:04:56-07:00
   
   

   NVD - CVE-2026-63807

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-20T01:04:56-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com