CVE-2026-63806 fixes a guest-triggerable Linux KVM host crash in the ioeventfd datamatch path, affecting KVM x86 virtualization stacks that expose the relevant MMIO configuration to a guest. The National Vulnerability Database published the record on July 19, identifying stable fixes in Linux kernel 6.12.95, 6.18.38, and 7.1.3, with the change also present in 7.2-rc1.
For Windows users and administrators, this is not a Hyper-V vulnerability. A standard Windows 11, Windows Server, Hyper-V, or WSL2 deployment does not use Linux KVM as its host hypervisor. The immediate exposure is instead in Linux-based virtualization environments—typically QEMU/KVM hosts—that may be running Windows guests, alongside Linux appliances and other virtual machines.
The practical risk is availability. Under the narrow conditions described in the kernel.org-originated advisory, code inside a guest VM can drive KVM into a
The vulnerable code lives in
The flawed assumption was an alignment assertion in the datamatch handling path. KVM’s x86 instruction emulator can process one guest store in fragments when that write crosses a guest-page boundary or encounters emulated MMIO. In the reported reproducer, a 16-byte write begins at offset
If the second fragment hits emulated MMIO and the destination has a datamatch-enabled ioeventfd at offset zero, KVM checks the fragment against the configured match value. The source pointer can then be aligned to four bytes while the configured match length requires eight-byte alignment. The old
That distinction matters: this is not a conventional out-of-bounds memory-corruption report. The guest is exploiting a valid but underappreciated emulator and MMIO edge case to reach an assertion that terminates host-kernel execution.
Simply removing the assertion would not have been sufficient. x86 processors generally tolerate unaligned memory reads, but directly dereferencing an unaligned pointer is undefined behavior under C rules and triggers sanitizer failures under configurations such as
That is a useful illustration of why virtualization vulnerabilities often look unexpectedly specific. The vulnerable condition is not merely “unaligned access”; it requires the intersection of an emulated store, a page split, MMIO handling, and a datamatch ioeventfd arrangement. But in a virtual machine, a guest can generate precisely crafted accesses indefinitely. An assumption that is safe for normal host code can become reachable once the host is emulating an attacker-controlled CPU.
The authoritative check is the vendor’s kernel changelog or security advisory for the exact installed package. For self-maintained kernels, verify that the KVM ioeventfd patch is present in the source tree or that the build includes one of the identified stable commits.
The affected arrangement is more likely on hosts that use QEMU/KVM with emulated or paravirtual devices relying on ioeventfd. Whether a particular VM can reach the condition depends on the host’s device configuration, specifically whether it has a datamatch-enabled ioeventfd mapping that lines up with the crafted split write. That means not every KVM deployment is equally exposed, but it is not a condition administrators should attempt to rule out manually as a substitute for patching.
For managed infrastructure, the operational priorities are straightforward:
Still, the demonstrated result is significant for KVM operators. A guest-originated trigger that reaches
The most important next step is therefore routine but non-negotiable: ensure KVM hosts have moved to a vendor kernel containing the fix. Windows guests operating under QEMU/KVM inherit the reliability of that Linux host, and CVE-2026-63806 is one more reminder that guest isolation depends as much on mundane emulator edge cases as on the hypervisor’s headline security architecture.
For Windows users and administrators, this is not a Hyper-V vulnerability. A standard Windows 11, Windows Server, Hyper-V, or WSL2 deployment does not use Linux KVM as its host hypervisor. The immediate exposure is instead in Linux-based virtualization environments—typically QEMU/KVM hosts—that may be running Windows guests, alongside Linux appliances and other virtual machines.
The practical risk is availability. Under the narrow conditions described in the kernel.org-originated advisory, code inside a guest VM can drive KVM into a
BUG_ON() assertion, producing a kernel oops and potentially taking down or destabilizing the host. That makes it especially relevant to multi-tenant KVM platforms and lab or CI hosts where tenants can execute arbitrary guest workloads.
A Page Boundary Turns Into a Host-Side BUG
The vulnerable code lives in virt/kvm/eventfd.c, in KVM’s ioeventfd handling. Ioeventfd is a KVM mechanism used by virtual-device implementations to notify userspace efficiently when a guest writes to a particular I/O or MMIO location. The optional datamatch mode adds a value comparison: the event is signaled only when the guest write matches a configured data value.The flawed assumption was an alignment assertion in the datamatch handling path. KVM’s x86 instruction emulator can process one guest store in fragments when that write crosses a guest-page boundary or encounters emulated MMIO. In the reported reproducer, a 16-byte write begins at offset
0xffc, so four bytes land at the end of one page and the remaining bytes are handled on the next page.If the second fragment hits emulated MMIO and the destination has a datamatch-enabled ioeventfd at offset zero, KVM checks the fragment against the configured match value. The source pointer can then be aligned to four bytes while the configured match length requires eight-byte alignment. The old
BUG_ON() treats that condition as impossible and deliberately faults the kernel.That distinction matters: this is not a conventional out-of-bounds memory-corruption report. The guest is exploiting a valid but underappreciated emulator and MMIO edge case to reach an assertion that terminates host-kernel execution.
The Fix Is Small, but It Removes an Old Assumption
The upstream patch replaces the assertion-driven aligned access withget_unaligned(), the Linux helper intended for safely reading values from potentially unaligned addresses. Kernel.org’s description says the reachable assertion had existed since 2009.Simply removing the assertion would not have been sufficient. x86 processors generally tolerate unaligned memory reads, but directly dereferencing an unaligned pointer is undefined behavior under C rules and triggers sanitizer failures under configurations such as
CONFIG_UBSAN_ALIGNMENT=y. Using get_unaligned() preserves the intended comparison while keeping the code valid for the compiler and for instrumented kernel builds.That is a useful illustration of why virtualization vulnerabilities often look unexpectedly specific. The vulnerable condition is not merely “unaligned access”; it requires the intersection of an emulated store, a page split, MMIO handling, and a datamatch ioeventfd arrangement. But in a virtual machine, a guest can generate precisely crafted accesses indefinitely. An assumption that is safe for normal host code can become reachable once the host is emulating an attacker-controlled CPU.
Fixed Kernel Versions Are Available, but Distribution Backports Still Matter
The CVE record marks Linux kernels from 2.6.32 onward as affected before the applicable fixes, and names these fixed upstream stable releases:- Linux kernel 6.12.95 includes the correction for the 6.12 stable series.
- Linux kernel 6.18.38 includes the correction for the 6.18 stable series.
- Linux kernel 7.1.3 includes the correction for the 7.1 stable series.
- Linux kernel 7.2-rc1 includes the change in the development line.
The authoritative check is the vendor’s kernel changelog or security advisory for the exact installed package. For self-maintained kernels, verify that the KVM ioeventfd patch is present in the source tree or that the build includes one of the identified stable commits.
KVM Hosts Running Windows Guests Need the Same Patch
A Windows guest does not need a Windows-side patch for CVE-2026-63806. The fault is in the Linux KVM module on the host, not in Windows kernel code, Windows device drivers, or guest applications. Updating a Windows Server VM, installing a Windows cumulative update, or changing a guest’s Hyper-V settings will not remediate an unpatched KVM host.The affected arrangement is more likely on hosts that use QEMU/KVM with emulated or paravirtual devices relying on ioeventfd. Whether a particular VM can reach the condition depends on the host’s device configuration, specifically whether it has a datamatch-enabled ioeventfd mapping that lines up with the crafted split write. That means not every KVM deployment is equally exposed, but it is not a condition administrators should attempt to rule out manually as a substitute for patching.
For managed infrastructure, the operational priorities are straightforward:
- Patch the Linux kernel on KVM hosts and reboot into the updated kernel.
- Confirm the running version after reboot rather than only confirming that a package was downloaded.
- Check vendor advisories when using a distribution kernel with backported fixes.
- Prioritize hosts that run untrusted, customer-controlled, CI-generated, or security-testing guest workloads.
- Avoid relying on guest operating-system updates, because the remediation point is the host kernel.
The Exposure Is Narrow, but the Failure Mode Is Unfriendly
NVD had not assigned a CVSS score as of July 20, and the entry does not provide a severity rating. That is reasonable caution at this early stage: exploitability depends on host-side KVM device setup, not just the guest’s ability to execute instructions.Still, the demonstrated result is significant for KVM operators. A guest-originated trigger that reaches
BUG_ON() can cause a host-kernel fault, disrupting every workload sharing that physical host. In a single-VM workstation lab, that may mean a crash and reboot; in a consolidation host, it can mean an outage far beyond the guest that initiated the condition.The most important next step is therefore routine but non-negotiable: ensure KVM hosts have moved to a vendor kernel containing the fix. Windows guests operating under QEMU/KVM inherit the reliability of that Linux host, and CVE-2026-63806 is one more reminder that guest isolation depends as much on mundane emulator edge cases as on the hypervisor’s headline security architecture.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:03:04-07:00
NVD - CVE-2026-63806
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:03:04-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
