CVE-2026-63807

What it actually does

This flaw affects the Linux kernel KVM x86 shadow MMU handling of hugepage recovery. During memory-slot updates, KVM can evaluate the maximum hugepage mapping level for a guest frame number that is outside the bounds of the target memory slot. That invalid bounds handling can trigger an out-of-bounds read from KVM memory-slot large-page metadata, commonly resulting in a host kernel page fault and crash. Because exploitation requires local access with the ability to create or control a KVM virtual machine, the primary realistic impact is denial of service of the virtualization host; however, the assigned CVSS vector also reflects high confidentiality and integrity impact due to the vulnerability occurring in privileged kernel memory-management code across a changed scope boundary.

Why it matters to the business

An authorized local user or process with access to KVM virtualization interfaces could crash a Linux virtualization host, disrupting all workloads running on that host and potentially causing service outages, failed jobs, data-processing interruption, and operational recovery work. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, but it affects kernel-level virtualization infrastructure where a single host crash can have broad business impact.

How an attack unfolds

An attacker first needs local privileges sufficient to interact with KVM, typically by running a VM or invoking KVM ioctls through a hypervisor, test harness, or virtualization management path. The attacker configures guest memory and page-table state so that a guest hugepage mapping extends below or outside the bounds of a KVM memory slot. When KVM faults in memory and later performs memory-slot changes or hugepage recovery, it may encounter a direct shadow page whose base guest frame number is outside the memory slot being processed. Vulnerable kernels query the maximum mapping level before confirming that the shadow page base guest frame number is contained in the slot, causing an out-of-bounds access to slot large-page metadata. The usual observable result is a host kernel page fault in KVM MMU code, followed by an oops or panic that can take the virtualization host and resident workloads offline.

How to fix it

Upgrade affected Red Hat Enterprise Linux 10 kernel packages to the fixed version: kernel 6.12.0-55.94.1.el10_0 or later, as provided by RHSA-2026:49030. Reboot into the updated kernel after installation; merely installing the package is not sufficient while the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by restricting membership in groups that can access KVM devices, limiting access to /dev/kvm, preventing untrusted users from launching VMs on shared hosts, disabling nested virtualization where not required, and isolating untrusted virtualization workloads onto patched or disposable hosts. If KVM is not required on a system, disable or unload KVM modules and prevent them from loading at boot, subject to operational requirements.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is fixed. On Red Hat Enterprise Linux 10 systems, verify that `uname -r` reports 6.12.0-55.94.1.el10_0 or a later vendor-fixed kernel. Confirm package state with the platform package manager and verify that systems were rebooted after the kernel update. Check that KVM modules were reloaded from the updated kernel by validating module paths and timestamps under the active kernel release. For exposure validation, identify systems with KVM enabled by checking for loaded `kvm` and `kvm_intel` or `kvm_amd` modules and the presence and permissions of `/dev/kvm`. Systems that allow untrusted local users or workloads to create KVM VMs should be prioritized for validation and remediation.

Typical attack path

1. Obtain local access to a Linux system where KVM is enabled and the attacker can create or control a virtual machine or issue KVM ioctls.
2. Create or manipulate guest memory regions and guest page-table entries involving hugepage-sized mappings near memory-slot boundaries.
3. Trigger KVM memory faulting and memory-slot update paths, such as operations that create direct shadow pages and later recover hugepages after 4 KiB mapping restrictions are lifted.
4. Cause KVM to process a shadow page whose base guest frame number is outside the target memory slot.
5. Trigger the vulnerable out-of-bounds access in KVM x86 MMU large-page metadata handling.
6. Crash the host kernel or KVM subsystem, resulting in denial of service for virtual machines on the host.

How to detect it

Look for evidence of host kernel crashes or oops events involving KVM x86 MMU hugepage recovery and memory-slot updates. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/messages`, `/var/log/kern.log`, crash dump metadata, hypervisor management logs, audit logs for access to `/dev/kvm`, and process execution logs showing VM creation or KVM stress tooling shortly before a crash. Focus on kernel stack traces containing `kvm_mmu_max_mapping_level`, `kvm_mmu_recover_huge_pages`, `kvm_set_memslot`, `kvm_set_memory_region`, or `kvm_vm_ioctl`, especially when paired with `BUG: unable to handle page fault` or `#PF: supervisor read access in kernel mode`. Also review local user activity and automation jobs that launched QEMU/KVM, custom VM fuzzers, or MMU stress tests around the time of the crash. There are no known network indicators because exploitation is local through KVM interfaces rather than a remote protocol.

• BUG: unable to handle page fault
• kvm_mmu_max_mapping_level
• kvm_mmu_recover_huge_pages
• kvm_set_memslot
• kvm_set_memory_region
• kvm_vm_ioctl
• #PF: supervisor read access in kernel mode
• #PF: error_code(0x0000) - not-present page
• Oops: Oops: 0000
• Comm: mmu_stress_test
• /dev/kvm
• kvm_intel
• kvm_amd
• modprobe kvm
• qemu-system-x86_64

What your security team should do

• Prioritize patching virtualization hosts and developer/build systems that allow local users, CI jobs, containers, or automation to create KVM virtual machines.
• Deploy the Red Hat fixed kernel 6.12.0-55.94.1.el10_0 or later and schedule a reboot to activate it.
• Inventory systems with `/dev/kvm` present and loaded KVM modules to identify exposed assets.
• Restrict access to KVM device nodes and virtualization-management tooling to trusted administrators until patching is complete.
• Review recent kernel crash, oops, panic, and hypervisor logs for KVM MMU page-fault signatures that may indicate attempted exploitation or stress testing.
• Consider temporary isolation of untrusted VM workloads from multi-tenant virtualization hosts until the fix is deployed.
• Track vendor advisories for downstream kernel rebuilds or live-patching availability if standard reboot-based patching is operationally difficult.