CVE-2026-63806

What it actually does

This flaw is a guest-triggerable denial-of-service condition in the Linux kernel KVM ioeventfd datamatch path. A specially crafted guest memory store that crosses a page boundary and then reaches emulated MMIO backed by a datamatch-enabled ioeventfd can cause KVM to evaluate an unaligned value pointer. The vulnerable code used BUG_ON() to enforce alignment, so the condition triggers a kernel BUG/Oops rather than being handled safely. On affected hosts, this can crash the kernel or destabilize the hypervisor, causing loss of availability for the host and resident virtual machines. The fix replaces the unsafe alignment assumption with get_unaligned(), avoiding undefined behavior while allowing KVM to process the access safely.

Why it matters to the business

Organizations using Linux KVM-based virtualization may be exposed to host-level availability disruption from code running inside a guest VM. Successful exploitation can crash or panic the virtualization host, interrupting hosted workloads and potentially causing downtime across multiple virtual machines on the same system. The issue is not known to be exploited in the wild, is not listed in CISA KEV, has low EPSS, and currently has no reported public exploit maturity, but it should still be prioritized for virtualization hosts because availability impact is high and the trigger is reachable from guest execution under the right device/MMIO configuration.

How an attack unfolds

An attacker first needs the ability to execute code inside a virtual machine running on an affected Linux KVM host. The guest then performs a memory store of a size and address alignment that causes the access to split across a page boundary. The first part of the write is handled as normal guest memory, while the second part lands on an emulated MMIO page associated with a datamatch-enabled ioeventfd. When KVM evaluates the datamatch for the second fragment, it uses an offset into the original destination value that may not be aligned for the ioeventfd length. On vulnerable kernels, that misalignment satisfies earlier range checks but then trips a BUG_ON() in ioeventfd_write(), leading to a kernel Oops/BUG and potential host crash. The practical result is denial of service rather than data theft or privilege escalation.

How to fix it

Apply the Linux kernel update from the operating system or hypervisor vendor that includes the KVM change replacing the guest-triggerable BUG_ON() in ioeventfd datamatch handling with get_unaligned(). Because no exact fixed package versions were provided, track vendor advisories for the affected kernel branches in use and update all KVM-capable virtualization hosts to a fixed kernel build. Reboot hosts into the fixed kernel after installation; merely installing kernel packages is not sufficient if the host continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by limiting who can run untrusted workloads on affected KVM hosts, isolating untrusted tenants/workloads onto patched or dedicated hosts, and disabling or avoiding risky virtual device configurations where operationally feasible. Treat mitigation as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm remediation by verifying that each virtualization host is running, not merely has installed, a kernel version containing the KVM ioeventfd get_unaligned() fix for this issue. Validate through vendor package metadata, changelogs, or source patches referencing the replacement of the ioeventfd datamatch BUG_ON() with get_unaligned(). Check that KVM modules loaded after reboot match the patched kernel build. Exposure exists primarily on systems with KVM enabled, especially hosts loading kvm, kvm_intel, or kvm_amd and running guest VMs. A negative validation should include: no vulnerable kernel running, KVM modules aligned to the patched kernel, successful host reboot into the fixed kernel, and no recurring kernel logs showing ioeventfd_write BUG/Oops traces.

Typical attack path

1. Obtain the ability to run code inside a guest VM on a KVM-based Linux virtualization host.
2. Identify or influence a guest device/MMIO path that uses datamatch-enabled ioeventfd handling, commonly through virtualized device emulation.
3. Issue a crafted guest store that begins near the end of a page so the write crosses into the next page.
4. Ensure the second page fragment targets emulated MMIO at an offset matching an ioeventfd datamatch region.
5. Trigger KVM's ioeventfd datamatch processing with an unaligned source pointer derived from the split store.
6. Cause the vulnerable BUG_ON() in the host kernel KVM module to fire, producing a kernel Oops/BUG and possible host-wide denial of service.

How to detect it

To assess prior exploitation or triggering, review host-side kernel logs, persistent journal entries, hypervisor logs, crash dumps, and monitoring alerts for kernel BUG/Oops traces involving KVM ioeventfd handling. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries from the kernel facility, kdump/vmcore records, hypervisor management logs, and availability monitoring events showing sudden host reboots or kernel panics. Focus on stack traces that include ioeventfd_write, __kvm_io_bus_write, kvm_io_bus_write, vcpu_mmio_write, x86_emulate_instruction, kvm_mmu_page_fault, kvm_arch_vcpu_ioctl_run, and loaded modules such as kvm, kvm_intel, or kvm_amd. Correlate any such event with guest activity immediately before the crash, especially VM workloads that performed unusual MMIO-heavy operations or custom device interaction. This issue does not provide strong network or file-based indicators by itself; detection is primarily through kernel crash telemetry and KVM stack traces.

• kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783
• ioeventfd_write+0x6c/0x70 [kvm]
• __kvm_io_bus_write+0x85/0xb0 [kvm]
• kvm_io_bus_write+0x53/0x80 [kvm]
• vcpu_mmio_write+0x66/0xf0 [kvm]
• emulator_read_write_onepage
• emulator_read_write
• x86_emulate_insn
• x86_emulate_instruction
• kvm_mmu_page_fault
• vmx_handle_exit
• kvm_arch_vcpu_ioctl_run
• kvm_vcpu_ioctl
• Modules linked in: kvm_intel kvm irqbypass
• Oops: invalid opcode: 0000
• RIP: 0010:ioeventfd_write
• ------------[ cut here ]------------
• ---[ end trace

What your security team should do

• Inventory Linux hosts running KVM or KVM-based virtualization and identify those running kernel builds that predate the vendor fix.
• Prioritize patching and rebooting multi-tenant, externally provided, or untrusted-workload virtualization hosts because a guest-triggered crash can affect many workloads at once.
• Monitor vendor advisories for exact fixed kernel package versions for each distribution and hypervisor appliance in use.
• Until patched, restrict untrusted guest execution on affected hosts and consider workload placement controls to isolate higher-risk VMs.
• Search historical kernel logs and crash dumps for KVM ioeventfd_write BUG/Oops indicators to determine whether the condition has already occurred.
• Ensure crash handling and live migration/HA policies are functioning so that host crashes do not create prolonged service outages.
• Because this is not KEV-listed and has low EPSS with no known public exploit maturity, prioritize according to virtualization criticality rather than internet exposure alone.