CVE-2026-64561

What it actually does

This is a race-condition flaw in the Linux KVM x86 memory-management unit. During shadow MMU page-fault handling, KVM can make MMU pages available, reclaim shadow pages, and invalidate an in-use root page table before checking whether the root is stale. KVM may then map guest memory through an invalid or obsolete root, causing newly created child shadow pages to inherit an invalid role while still being placed on the active MMU page list. That violates KVM internal invariants and can destabilize the host kernel. The most likely technical impact is host-side KVM malfunction or denial of service affecting virtual machines; reliable privilege escalation or code execution is not indicated by the provided data.

Why it matters to the business

Organizations running affected Red Hat Enterprise Linux KVM hosts could experience virtualization instability, guest outages, or host kernel crashes if the flaw is triggered. The issue is not currently in CISA KEV, is not marked as ransomware-associated, and has a low EPSS score of 0.00157 with no public exploit maturity reported, so broad exploitation urgency is lower than for internet-facing remote-code-execution flaws. However, virtualization hosts are high-impact infrastructure: a single host failure can disrupt many workloads. The affected Red Hat kernel and kernel-rt packages are widely deployed in enterprise environments, so patching should be prioritized for systems that run untrusted, multi-tenant, or externally supplied virtual machines.

How an attack unfolds

An attacker needs a path to execute or control code inside a virtual machine running on an affected KVM x86 host. From the guest, the attacker attempts to create timing and memory-management conditions that force KVM into shadow MMU page-fault handling while shadow pages are being reclaimed. If the reclaim operation invalidates an in-use root before KVM performs the stale-root check, KVM can continue mapping through that invalid root and create invalid child shadow pages on the active list. The resulting inconsistent KVM MMU state may produce kernel warnings, VM failures, or a host crash. The provided intelligence names Zapscape in threat-actor context, but exploit maturity is listed as None; defenders should treat actor mention as monitoring context rather than proof of widespread weaponized exploitation.

How to fix it

Apply the vendor-fixed Red Hat kernel update and reboot into the fixed kernel. Fixed package baselines provided are: kernel for Red Hat Enterprise Linux 10 fixed in 6.12.0-211.39.1.el10_2 via RHSA-2026:45192; kernel for Red Hat Enterprise Linux 8 fixed in 4.18.0-477.156.1.el8_8 via RHSA-2026:45192; kernel for Red Hat Enterprise Linux 9 fixed in 5.14.0-570.131.1.el9_6 via RHSA-2026:45192; kernel-rt for Red Hat Enterprise Linux 8 fixed in 4.18.0-553.147.1.rt7.488.el8_10 via RHSA-2026:45192. Kernel updates are not fully effective until the host is rebooted into the updated kernel. Where immediate patching is not possible, reduce exposure by avoiding untrusted guest workloads on affected KVM hosts, migrating sensitive workloads to patched hosts, limiting who can create or control virtual machines, and considering temporary suspension of KVM-based virtualization on high-risk systems.

How to confirm the fix worked

Confirm both package installation and the running kernel. On Red Hat systems, use package-management queries such as `rpm -q kernel kernel-rt` or `dnf updateinfo info RHSA-2026:45192` to verify that the fixed advisory level is installed, then use `uname -r` after reboot to confirm the active kernel is at or above the applicable fixed version. Validate that KVM hosts have been restarted after the update; merely installing the package is insufficient if the old kernel is still running. For exposure assessment, identify systems with KVM modules loaded, such as `kvm` and `kvm_intel` or `kvm_amd`, and prioritize those running guest VMs. For functional validation, perform controlled VM start, migration, and memory-stress tests on patched hosts while monitoring kernel logs for KVM MMU warnings or oops events.

Typical attack path

1. Gain the ability to run code in, administer, or supply a virtual machine on an affected Linux KVM x86 host.
2. Generate guest memory-access patterns that cause repeated KVM shadow MMU page faults.
3. Create pressure on KVM shadow MMU page allocation/reclamation so shadow pages are reclaimed while a page fault is being serviced.
4. Trigger the stale-root race where an in-use root is invalidated before KVM checks whether the root is obsolete.
5. Cause KVM to populate invalid shadow page structures, violating MMU invariants.
6. Leverage the resulting host-side instability to crash or disrupt the KVM host or affected virtual machines.

How to detect it

There are no reliable public, CVE-specific compromise indicators provided for this issue. Detection should focus on retrospective signs of attempted triggering or successful impact on KVM hosts. Review host-side logs, not just guest logs: `journalctl -k`, `/var/log/messages`, `/var/log/kern.log` where present, hypervisor management logs, crash dumps under kdump storage, and virtualization orchestration events. Look for kernel warnings, oops, BUG reports, panics, or stack traces involving KVM x86 MMU code around the time of guest memory pressure, VM resets, or host instability. Correlate these events with VM lifecycle actions, unusual guest workload spikes, repeated page-fault-heavy activity, memory overcommit, live migration, or rapid VM creation/destruction. Because crashes or warnings in KVM can have many benign or unrelated causes, treat matches as triage leads requiring kernel-version validation, crash dump analysis, and timeline correlation rather than definitive proof of exploitation.

What your security team should do

• Inventory all Red Hat Enterprise Linux KVM and kernel-rt virtualization hosts and map them to the affected kernel streams.
• Prioritize patching and rebooting hosts that run untrusted, multi-tenant, externally supplied, or high-criticality virtual machines.
• Upgrade to the fixed RHSA-2026:45192 kernel versions or later and verify the running kernel with `uname -r` after reboot.
• Temporarily restrict VM creation, guest administrative access, and untrusted workload placement on unpatched KVM hosts.
• Monitor hypervisor kernel logs for KVM MMU warnings, host kernel oops events, unexplained VM resets, and host crashes until remediation is complete.
• Review virtualization platform incident timelines for unusual host instability since publication on 2026-08-04, especially where guest activity preceded host faults.
• Track any additional reporting involving Zapscape, but do not assume active exploitation solely from the current low EPSS and no-known-exploit status.