CVE-2026-64247: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64247 Overview

CVE-2026-64247 is an out-of-bounds read vulnerability in the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem, specifically in the x86 Hyper-V paravirtualization code. The flaw resides in hv_is_vp_in_sparse_set(), which fails to bound-check the virtual processor (VP) ID when querying sparse bank sets. When handling a paravirtual TLB flush for an L2 guest, the VP ID is copied verbatim from the enlightened VMCS without validating that it falls within the 4096 limit permitted by the Hyper-V Top-Level Functional Specification (TLFS).

Critical Impact
A local attacker with the ability to run a nested guest can trigger an out-of-bounds read in kernel memory, potentially disclosing kernel data or destabilizing the host hypervisor.

Affected Products

Linux kernel versions containing the KVM x86 Hyper-V sparse bank handling code
Hosts running nested virtualization with enlightened VMCS enabled
Systems exposing KVM to unprivileged or semi-privileged users via /dev/kvm

Discovery Timeline

2026-07-24 - CVE-2026-64247 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64247

Vulnerability Analysis

The vulnerability is an out-of-bounds read triggered inside hv_is_vp_in_sparse_set() in the KVM module. Hyper-V's TLFS defines sparse VP sets containing at most 64 banks of 64 vCPUs, capping addressable VP IDs at 4096. The affected code path receives a VP ID from the enlightened VMCS structure supplied by an L1 guest and uses it directly as an index without validating the upper bound.

When the KVM hypercall handler processes a paravirtual TLB flush request from an L1 hypervisor targeting an L2 vCPU, kvm_hv_flush_tlb() calls into the sparse bank query. If the L1 guest supplies a VP ID greater than 4095, the resulting bank index exceeds the size of the sparse bank array, producing the KASAN-reported read past the allocated buffer.

Root Cause

The root cause is missing input validation on attacker-controlled data crossing the guest-to-host trust boundary. The VP ID copied from the enlightened VMCS is treated as trusted despite being writable by the L1 guest. Without the bounds check, hv_is_vp_in_sparse_set() computes an index that dereferences memory outside the sparse bank structure.

Attack Vector

Exploitation requires local privileges on the host sufficient to run a KVM guest that itself acts as an L1 hypervisor and enables enlightened VMCS. The attacker crafts an enlightened VMCS containing a VP ID above 4095 and issues a Hyper-V paravirtual TLB flush hypercall targeting an L2 vCPU. The kernel then performs an out-of-bounds read, as demonstrated by the KASAN use-after-free splat referencing hv_is_vp_in_sparse_set+0x85/0x100 inside kvm_hv_flush_tlb() and kvm_hv_hypercall(). The read may leak kernel memory contents or, depending on adjacent memory state, cause a host panic and denial of service.

No verified public exploit code is available. See the linked upstream commits for the technical fix details: Linux Kernel Commit 4721f816 and Linux Kernel Commit e36095d8.

Detection Methods for CVE-2026-64247

Indicators of Compromise

KASAN reports naming hv_is_vp_in_sparse_set, kvm_hv_flush_tlb, or kvm_hv_hypercall in dmesg output on hosts with KASAN enabled.
Unexpected host kernel oops or panic traces originating from the kvm or kvm_intel modules while nested guests are running.
Guest workloads issuing anomalous volumes of Hyper-V paravirtual TLB flush hypercalls (HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST variants) targeting L2 vCPUs.

Detection Strategies

Monitor kernel logs for KASAN or general protection fault traces referencing KVM Hyper-V symbols on hypervisor hosts.
Audit /dev/kvm access to identify unprivileged users or containers with the capability to launch nested guests.
Correlate host crashes with concurrent nested-virtualization activity from tenant guests in multi-tenant environments.

Monitoring Recommendations

Enable kernel crash dump collection (kdump) on KVM hosts to capture forensic evidence of exploitation attempts.
Forward host dmesg and journald logs to a central analytics platform for kernel-fault pattern matching.
Track the running kernel version across the fleet and flag hosts still on pre-patch builds that permit nested virtualization.

How to Mitigate CVE-2026-64247

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the NVD advisory to all KVM hypervisor hosts.
Disable nested virtualization on hosts that do not require it by setting the kvm_intel.nested=0 or kvm_amd.nested=0 module parameter.
Restrict /dev/kvm access to trusted service accounts and remove it from untrusted container or workload contexts.

Patch Information

The fix adds an explicit bounds check on the VP ID before indexing into the sparse bank array and introduces a compile-time assertion tying the maximum bank count to the passed-in mask width. Distributions should pull the following upstream commits: 4721f816, 83c2f52c, d18756b1, e36095d8, and f636cf6a.

Workarounds

Disable enlightened VMCS support for nested guests until patched kernels are deployed.
Prevent unprivileged users from creating KVM instances by tightening group ownership and permissions on /dev/kvm.
Isolate multi-tenant KVM workloads on hosts running a patched kernel and quarantine untrusted tenants from nested-virtualization-capable pools.

bash

# Configuration example: disable KVM nested virtualization
# Intel hosts
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

# AMD hosts
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_amd && sudo modprobe kvm_amd

# Verify nested support is disabled
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || \
  cat /sys/module/kvm_amd/parameters/nested