CVE-2026-43265

What it actually does

CVE-2026-43265 is a local denial-of-service flaw in the Linux kernel KVM x86 virtualization subsystem involving nested virtualization event handling. When a virtual CPU exits a blocking state while an L2 nested guest is active, KVM could treat an -EBUSY condition during nested event checks as a userspace exit, often producing a spurious KVM_EXIT_UNKNOWN. A privileged local actor with access to KVM device interfaces or VM management capabilities can place a vCPU into an architecturally unexpected state by manipulating MP_STATE and/or injected events, causing the affected virtual machine process to fail or terminate. The primary impact is guest availability loss; confidentiality and integrity are not directly affected by the described flaw.

Why it matters to the business

Organizations running Linux KVM virtualization may experience unexpected virtual machine crashes or service interruptions if a local user, VM-management component, or compromised virtualization control plane can trigger the vulnerable state. The risk is most relevant for multi-tenant virtualization hosts, developer platforms, CI systems, cloud infrastructure, and environments that allow nested virtualization. Although the EPSS score is low, the issue is 97 days past publication and affects a core infrastructure component, so exposed virtualization hosts should be patched through normal kernel maintenance windows, with higher priority where untrusted users can create, configure, or control KVM guests.

How an attack unfolds

An attacker first needs local privileges sufficient to interact with KVM or a VM management stack on an affected Linux host. They create or control a KVM virtual machine using nested virtualization, then manipulate vCPU state, such as MP_STATE or injected exception, interrupt, or NMI state, to create a condition KVM expects should not occur: a vCPU entering or leaving a blocking state while L2 execution has a pending or injected event. When the vCPU wakes, vulnerable kernels mishandle the -EBUSY result from nested event checking and may exit to userspace with a spurious KVM_EXIT_UNKNOWN. Depending on the VMM behavior, this can cause the VM process to terminate or the guest to become unavailable, resulting in denial of service for workloads running in that VM.

How to fix it

Apply a Linux kernel update that includes the upstream KVM x86 fix to ignore -EBUSY when checking nested events after vcpu_block() wakeup in nested virtualization scenarios. No exact fixed package versions were provided in the input, so use the latest security-supported kernel from the relevant Linux distribution or vendor advisory channel. Prioritize KVM hosts that run nested virtualization, allow untrusted users to manage VMs, or support multi-tenant workloads. If immediate patching is not possible, reduce exposure by disabling nested virtualization where it is not required, restricting access to /dev/kvm and VM management APIs, limiting who can perform vCPU state manipulation or event injection operations, and isolating untrusted virtualization workloads onto patched or dedicated hosts.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version includes the vendor backport or upstream fix for the KVM x86 nested-event -EBUSY handling issue. Reboot into the patched kernel where required, because kernel package installation alone is not sufficient if the host is still running the old kernel. Validate exposure by checking whether KVM is enabled, whether /dev/kvm exists, whether nested virtualization is enabled for Intel or AMD KVM modules, and whether untrusted users or automation can create or control VMs. Where safe, use vendor regression tests or KVM selftests for nested virtualization and vCPU state handling to confirm that crafted nested-event wakeups no longer produce unexpected KVM_EXIT_UNKNOWN failures or VM termination.

Typical attack path

1. Obtain local access to a Linux host with KVM enabled or gain control over a process or service that can create or manage KVM virtual machines.
2. Create or access a VM configuration that uses x86 KVM nested virtualization, with an active L2 guest context.
3. Use KVM ioctls or a VM management interface to manipulate vCPU MP_STATE and/or inject events such as exceptions, interrupts, or NMIs into an unexpected state.
4. Trigger a vCPU wakeup from a blocking state while nested L2 execution is active.
5. Cause KVM to mishandle the nested event check and return a spurious userspace exit, commonly KVM_EXIT_UNKNOWN.
6. Rely on the VMM or management layer to terminate, reset, or destabilize the affected VM, causing workload outage.

How to detect it

To determine whether this flaw was already triggered, review host kernel logs, hypervisor logs, QEMU process output, libvirt logs, systemd journal entries, and VM lifecycle events for unexplained guest termination or resets involving KVM nested virtualization. Focus on events showing KVM_EXIT_UNKNOWN, unexpected QEMU exits, vCPU state errors, nested VM activity, or VM deaths shortly after vCPU blocking or wakeup behavior. Correlate suspected events with local user activity, VM creation or control operations, access to /dev/kvm, libvirt API calls, QEMU monitor commands, and automation jobs that can manipulate vCPU state or inject interrupts. Because this issue is a denial-of-service condition rather than code execution, durable host-level IOCs may be limited; detection is primarily behavioral and log-based, centered on unexpected VM process termination and KVM unknown-exit messages.

• KVM_EXIT_UNKNOWN
• kvm: KVM_EXIT_UNKNOWN
• unexpected KVM_EXIT_UNKNOWN
• qemu-system-x86_64
• /dev/kvm
• /var/log/libvirt/qemu/
• /var/log/libvirt/libvirtd.log
• /var/log/libvirt/qemu/*.log
• nested virtualization
• kvm_intel nested=1
• kvm_amd nested=1
• unknown exit reason
• VM terminated unexpectedly
• Domain crashed
• Domain unexpectedly terminated
• MP_STATE
• injected event
• injected interrupt
• injected exception
• NMI injection

What your security team should do

• Inventory Linux hosts running KVM, especially those with nested virtualization enabled or multi-tenant VM management access.
• Patch affected virtualization hosts to a vendor kernel containing the KVM x86 fix, then reboot and verify the active kernel version.
• Prioritize hosts where non-administrative users, CI jobs, developers, or tenants can create or control KVM guests.
• Temporarily disable nested virtualization on hosts that do not require it.
• Restrict access to /dev/kvm, libvirt, QEMU monitor interfaces, and VM management APIs to trusted administrators and service accounts only.
• Monitor virtualization logs for unexplained VM termination, KVM_EXIT_UNKNOWN, nested virtualization errors, and QEMU or libvirt crashes.
• Review recent VM outages on KVM hosts for patterns involving nested guests, injected interrupts, MP_STATE changes, or unexpected userspace exits.
• Ensure host crash, VM lifecycle, libvirt, QEMU, and kernel logs are retained long enough to investigate suspected denial-of-service activity.