[PATCH] KVM: SVM: handle wraparound of asid_generation

[PATCH] KVM: SVM: handle wraparound of asid_generation

[suryasaimadhu]

If asid_generation wraps around to 0, it matches the initial
value of svm->current_vmcb->asid_generation (0), causing KVM
to skip calling new_asid() and potentially reuse stale ASIDs.

Fix this by skipping 0 when incrementing asid_generation.

Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
 arch/x86/kvm/svm/svm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 9658ce4e0..fafd0af5d 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1900,7 +1900,8 @@ static void svm_update_exception_bitmap(struct kvm_vcpu *vcpu)
 static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd)
 {
 	if (sd->next_asid > sd->max_asid) {
-		++sd->asid_generation;
+		if (!++sd->asid_generation)
+			sd->asid_generation = 1;
 		sd->next_asid = sd->min_asid;
 		svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
 		vmcb_mark_dirty(svm->vmcb, VMCB_ASID);
-- 
2.47.3

Re: [PATCH] KVM: SVM: handle wraparound of asid_generation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch claims to fix a 64-bit ASID generation wraparound, but provides an incomplete solution that only shifts the theoretical ABA vulnerability from generation 0 to generation 1, and fails to remove the corresponding FIXME comment.
--

commit ecd299cb836eda8be32eeffedf37f3e076185761
Author: suryasaimadhu <suryasaimadhu369@gmail.com>

KVM: SVM: handle wraparound of asid_generation

If asid_generation wraps around to 0, it matches the initial
value of svm->current_vmcb->asid_generation (0), causing KVM
to skip calling new_asid() and potentially reuse stale ASIDs.

Fix this by skipping 0 when incrementing asid_generation.

> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 24d59ccfa40d9..cfb9952f7c1f6 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1794,7 +1794,8 @@ static void svm_update_exception_bitmap(struct kvm_vcpu *vcpu)
>  static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd)
>  {
>  	if (sd->next_asid > sd->max_asid) {
> -		++sd->asid_generation;
> +		if (!++sd->asid_generation)
> +			sd->asid_generation = 1;

[Severity: Medium]
Does skipping generation 0 fully resolve the wraparound issue, or does it
merely shift the theoretical ABA vulnerability to generation 1?

If a VMCB happens to sleep for an entire 2^64 generation cycle and wakes up
when the generation counter reaches 1 again, wouldn't it incorrectly match
the wrapped generation 1 and reuse a stale ASID?

Also, since this patch aims to handle the wraparound, should it remove the
explicit "/* FIXME: handle wraparound of asid_generation */" comment
located in pre_svm_run() just before the new_asid() call?

>  		sd->next_asid = sd->min_asid;
>  		svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
>  		vmcb_mark_dirty(svm->vmcb, VMCB_ASID);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094047.255954-1-suryasaimadhu369@gmail.com?part=1

Re: [PATCH] KVM: SVM: handle wraparound of asid_generation

[Sean Christopherson]

On Thu, Jun 25, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The patch claims to fix a 64-bit ASID generation wraparound, but provides an incomplete solution that only shifts the theoretical ABA vulnerability from generation 0 to generation 1, and fails to remove the corresponding FIXME comment.
> --
> 
> commit ecd299cb836eda8be32eeffedf37f3e076185761
> Author: suryasaimadhu <suryasaimadhu369@gmail.com>
> 
> KVM: SVM: handle wraparound of asid_generation
> 
> If asid_generation wraps around to 0, it matches the initial
> value of svm->current_vmcb->asid_generation (0), causing KVM
> to skip calling new_asid() and potentially reuse stale ASIDs.
> 
> Fix this by skipping 0 when incrementing asid_generation.
> 
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index 24d59ccfa40d9..cfb9952f7c1f6 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -1794,7 +1794,8 @@ static void svm_update_exception_bitmap(struct kvm_vcpu *vcpu)
> >  static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd)
> >  {
> >  	if (sd->next_asid > sd->max_asid) {
> > -		++sd->asid_generation;
> > +		if (!++sd->asid_generation)
> > +			sd->asid_generation = 1;
> 
> [Severity: Medium]
> Does skipping generation 0 fully resolve the wraparound issue, or does it
> merely shift the theoretical ABA vulnerability to generation 1?
> 
> If a VMCB happens to sleep for an entire 2^64 generation cycle and wakes up
> when the generation counter reaches 1 again, wouldn't it incorrectly match
> the wrapped generation 1 and reuse a stale ASID?

Yeah, properly "fixing" this would require poking every vCPU in the system.

I don't see any value in trying to make this bit of code less ugly.  In practice,
the generation is never going to wrap.  Even if the CPU were able to increment
the generation every *cycle*, a CPU running at 6ghz would only overflow after
~97 years.

And Yosry's nSVM TLB flushing series completely eliminates the generation scheme:
https://lore.kernel.org/all/20260616004155.1435766-10-yosry@kernel.org