CVE-2026-68093

What it actually does

This is a Linux KVM vulnerability in the AMD SVM virtualization path involving Address Space Identifier generation during physical CPU hotplug events. When a physical CPU is taken offline and brought back online, the per-CPU ASID generation can be reset in a way that allows a previously scheduled-out vCPU to resume using an ASID that has since been reassigned to a vCPU from another VM. That can cause stale Nested Page Table TLB translations to be reused across VM boundaries. The observable result is typically incorrect guest physical address translation, KVM internal errors, and failed instruction emulation, especially around FPU/XSave instructions such as XRSTOR or STMXCSR. The primary practical impact is VM instability or denial of service, with a theoretical virtualization isolation concern because translations from different VMs may collide on the same physical CPU.

Why it matters to the business

Organizations running Linux KVM virtualization on AMD SVM-capable hosts may experience guest crashes, workload disruption, or hypervisor instability after CPU hotplug operations. The issue is most relevant to cloud, hosting, CI, and virtualization platforms that online or offline CPUs for maintenance, power management, capacity management, or hardware lifecycle operations. There is no indication of active exploitation or ransomware use, and no public exploit maturity is reported, but because the flaw affects VM isolation primitives, it should be treated as important for multi-tenant or high-availability virtualization environments.

How an attack unfolds

An attacker would need conditions that allow the ASID collision to occur on an affected KVM host. In a realistic scenario, this requires AMD SVM-based KVM, active VMs, vCPUs that remain scheduled out or blocked, and a physical CPU hotplug cycle on the last CPU where a target vCPU ran. After the CPU is brought back online, other vCPUs may be assigned ASIDs from the reset generation sequence. If a previously blocked vCPU resumes on the same physical CPU with a stale but apparently valid ASID generation, KVM may fail to allocate a fresh ASID. Two vCPUs from different VMs can then share the same ASID on that CPU, causing stale NPT TLB entries to be used. The outcome is generally a KVM internal error and VM failure rather than a straightforward remote-code-execution path. Practical exploitation likely requires host-level operational influence over CPU hotplug or highly specific timing and scheduling conditions; a normal remote network attacker is not expected to be able to trigger this directly.

How to fix it

Upgrade the Linux kernel to a version or vendor backport that includes the KVM SVM fix changing CPU-online behavior so asid_generation is incremented rather than reset during svm_enable_virtualization_cpu(). Because no exact fixed versions were provided, use distribution kernel advisories and package changelogs for CVE-2026-68093 or the referenced KVM SVM ASID-generation hotplug fix. Prioritize AMD-based KVM hypervisors, especially those running multi-tenant or production VMs. If immediate patching is not possible, reduce exposure by avoiding CPU hotplug operations on affected hosts, disabling automated CPU online/offline workflows where feasible, draining VMs before planned CPU hotplug maintenance, and rebooting or evacuating hosts after risky CPU topology changes. Intel VMX-only KVM hosts are not expected to be affected by this specific SVM path.

How to confirm the fix worked

Confirm that the running kernel includes the patched KVM SVM behavior by checking vendor advisories, kernel changelogs, package versions, or source/backport evidence for the asid_generation increment-on-CPU-online change. Validate exposure by identifying Linux KVM hosts using AMD SVM and reviewing whether CPU hotplug is enabled or used operationally. After remediation, perform controlled CPU offline/online testing only in a non-production environment with active KVM guests and monitor for absence of KVM internal errors, NPT page-fault anomalies, and emulation failures. Also verify that all hypervisors have been rebooted into the fixed kernel if the kernel package was updated but not yet activated.

Typical attack path

1. Identify a Linux KVM host using AMD SVM virtualization and an affected kernel build.
2. Run or influence VM workloads so one vCPU remains blocked or scheduled out after running on a specific physical CPU.
3. Cause or wait for that physical CPU to go through an offline-to-online hotplug cycle.
4. Allow other vCPUs, potentially from other VMs, to run on the re-online CPU and consume ASIDs from the reset ASID pool.
5. Resume the original vCPU on the same physical CPU while its stored ASID generation still appears current.
6. Trigger stale NPT TLB translation reuse, leading to incorrect guest memory translation, KVM internal errors, and possible VM termination or instability.

How to detect it

To determine whether this issue may already have manifested, review hypervisor-side logs rather than guest-only logs. Focus on Linux kernel logs, journald, dmesg, syslog, virtualization management events, and VM crash records around CPU hotplug events. Look for CPU offline/online messages followed by KVM internal errors, emulation failures, NPT page-fault anomalies, or guest terminations. The most relevant artifacts are KVM messages reporting Suberror: 1, emulation failure, faulting guest physical addresses outside the VM's assigned memory range, and failed emulation of XRSTOR or STMXCSR. Correlate these with physical CPU hotplug operations, host power-management events, maintenance automation, or capacity-management actions. There are no known public threat actors or ransomware campaigns associated with this issue, so detection should focus on operational symptoms and suspiciously timed host-level CPU hotplug activity rather than known attacker infrastructure.

• KVM internal error. Suberror: 1
• KVM internal error
• emulation failure
• NPT page fault
• faulting GPA
• XRSTOR
• STMXCSR
• CPU offline
• CPU online
• smpboot: CPU
• kvm: KVM internal error
• kvm_amd

What your security team should do

• Inventory Linux KVM hypervisors and prioritize AMD SVM-based systems for assessment and patching.
• Apply vendor kernel updates or live patches that include the KVM SVM ASID-generation hotplug fix.
• Treat multi-tenant virtualization hosts and high-availability compute clusters as the highest priority, even though the issue is not currently in CISA KEV and has no reported exploit maturity.
• Temporarily restrict or disable CPU hotplug workflows on affected hosts until patched.
• Review recent host kernel logs for KVM internal errors, emulation failures, and NPT page-fault anomalies following CPU offline/online events.
• Coordinate with virtualization operations teams to drain or reboot affected hosts after patching so the fixed kernel is actually running.
• Add monitoring for KVM internal error patterns that may indicate stale TLB translation symptoms or guest instability.