From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: suryasaimadhu <suryasaimadhu369@gmail.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: SVM: handle wraparound of asid_generation
Date: Thu, 25 Jun 2026 07:47:01 -0700 [thread overview]
Message-ID: <aj0_ZWALxEcvlUIy@google.com> (raw)
In-Reply-To: <20260625095846.EF9271F000E9@smtp.kernel.org>
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
prev parent reply other threads:[~2026-06-25 14:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 9:40 [PATCH] KVM: SVM: handle wraparound of asid_generation suryasaimadhu
2026-06-25 9:58 ` sashiko-bot
2026-06-25 14:47 ` Sean Christopherson [this message]
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=aj0_ZWALxEcvlUIy@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=suryasaimadhu369@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox