Re: [PATCH 11/24] KVM: SEV: Make it more obvious when KVM is writing back the current PSC index

[Sean Christopherson <seanjc@google.com>]

On Fri, May 29, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -3947,7 +3947,7 @@ static int snp_begin_psc(struct vcpu_svm *svm)
> >  	}
> >  
> >  	/* Find the start of the next range which needs processing. */
> > -	for (idx = idx_start; idx <= idx_end; idx++, hdr->cur_entry++) {
> > +	for (idx = idx_start; idx <= idx_end; idx++) {
> >  		entry_start = READ_ONCE(entries[idx]);
> >  
> [ ... ]
> > @@ -3974,6 +3974,14 @@ static int snp_begin_psc(struct vcpu_svm *svm)
> >  
> >  		if (npages)
> >  			break;
> > +
> > +		/*
> > +		 * Increment the guest-visible index to communicate the current
> > +		 * entry back to the guest, e.g. in case of failure.  No need
> > +		 * for READ_ONCE() as KVM doesn't consume the field, i.e. a
> > +		 * misbehaving guest can only break itself.
> > +		 */
> > +		hdr->cur_entry++;
> >  	}
> >  
> >  	if (idx > idx_end) {
> 
> [Severity: High]
> This is a pre-existing issue, but since we're examining how a misbehaving 
> guest affects the PSC processing loop, is it possible for a guest to trigger 
> a soft lockup here?
> 
> Looking at snp_begin_psc(), if the guest submits an unsupported PSC operation,
> we hit the default case and loop back:
> 
> next_range:
>     idx_start = READ_ONCE(hdr->cur_entry);
>     ...
>     switch (entry_start.operation) {
>     ...
>     default:
>         __snp_complete_one_psc(svm);
>         goto next_range;
>     }
> 
> If a malicious guest concurrently resets hdr->cur_entry back to 0 in the
> GHCB shared memory, could the host get trapped continuously reading an
> index of 0 and re-processing the same unsupported entry? 

Already fixed in patch 16, "KVM: SEV: Read start/end indices of PSC requests
exactly once per #VMGEXIT".