CVE-2026-68093 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug
If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used.
svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid.
Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event:
1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1.
2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug.
3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B.
Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations.
The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement.
Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides within the KVM hypervisor implementation for AMD SVM (Secure Virtual Machine) technology in the Linux kernel, specifically addressing issues related to ASID (Address Space Identifier) management during CPU hotplug operations. This flaw manifests when a virtual CPU remains scheduled out or blocked while the physical CPU it was previously running on undergoes a hotplug cycle involving offline and online states. The core issue stems from improper handling of ASID generation counters in the SVM virtualization framework, which leads to potential ASID collisions between different virtual machines running on the same physical CPU after such events.
The technical root cause lies in how the svm_enable_virtualization_cpu() function manages the asid_generation counter during CPU online events. Upon detection of a CPU going online, this function resets asid_generation to 1 and sets next_asid to max_asid + 1, effectively creating a scenario where subsequent ASID allocation can reuse identifiers from previous generations. This behavior becomes problematic when multiple virtual machines are involved, as the same ASID value might be assigned to different vCPUs across distinct VMs after a hotplug event, leading to TLB (Translation Lookaside Buffer) translation conflicts.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially causing complete system instability or security breaches. When affected vCPUs execute with stale ASIDs, they share the same Nested Page Table (NPT) TLB entries, resulting in incorrect memory mappings that manifest as KVM internal errors with Suberror: 1 and emulation failures. The symptom typically presents as NPT page faults reporting faulting GPAs (Guest Physical Addresses) outside normal VM memory ranges, indicating that stale translations are being used instead of fresh ones. The hypervisor's fallback mechanism attempts to emulate FPU/XSave instructions such as XRSTOR and STMXCSR, but these emulations fail due to incomplete implementation, ultimately leading to system crashes or unpredictable behavior.
The fix implemented addresses the fundamental flaw by changing the behavior from resetting asid_generation to 1 to incrementing it instead during CPU online events. This modification ensures that each hotplug cycle advances the generation counter beyond any values previously observed by vCPUs on that physical CPU. The solution maintains backward compatibility since module loading initializes asid_generation at 0, making the first increment produce the same result as the previous reset behavior. This approach guarantees that the generation check performed in pre_svm_run() reliably forces new_asid() allocation for every vCPU after each hotplug cycle, preventing any possibility of ASID reuse between different virtual machines.
This vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and represents a classic race condition scenario in virtualized environments. The issue also maps to ATT&CK technique T1059.007 (Command and Scripting Interpreter: Python) through the potential for exploitation via automated VM management scripts that might trigger hotplug events, though more directly it relates to T1496 (Resource Hijacking) in terms of how the flaw enables incorrect resource sharing between virtual machines. The fix demonstrates proper memory management principles by ensuring unique identifier generation across system state transitions, which is crucial for maintaining isolation guarantees in virtualized computing environments where security boundaries must remain intact even during dynamic hardware configuration changes.