From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-68093: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug
Date: Mon, 10 Aug 2026 13:56:50 +0200 [thread overview]
Message-ID: <2026081050-CVE-2026-68093-c08f@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
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.
The Linux kernel CVE team has assigned CVE-2026-68093 to this issue.
Affected and fixed versions
===========================
Issue introduced in 2.6.21 with commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb and fixed in 6.6.148 with commit 60283726f2845bd78b95efbd0e50b93944780477
Issue introduced in 2.6.21 with commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb and fixed in 6.12.101 with commit 7508916b4b55d6f5ecc68cd09774dabd3a6b4440
Issue introduced in 2.6.21 with commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb and fixed in 6.18.42 with commit 0f33b1c457c2199ed130b92cc2ff363a3f7b9415
Issue introduced in 2.6.21 with commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb and fixed in 7.1.6 with commit 6b542d116acecb83a1ca34e8eace304cff6a4ec9
Issue introduced in 2.6.21 with commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb and fixed in 7.2-rc4 with commit 25f744ffa0c8e799e06250ce2e618367b166b0d4
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-68093
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
arch/x86/kvm/svm/svm.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/60283726f2845bd78b95efbd0e50b93944780477
https://git.kernel.org/stable/c/7508916b4b55d6f5ecc68cd09774dabd3a6b4440
https://git.kernel.org/stable/c/0f33b1c457c2199ed130b92cc2ff363a3f7b9415
https://git.kernel.org/stable/c/6b542d116acecb83a1ca34e8eace304cff6a4ec9
https://git.kernel.org/stable/c/25f744ffa0c8e799e06250ce2e618367b166b0d4
reply other threads:[~2026-08-10 12:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026081050-CVE-2026-68093-c08f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.