Re: [PATCH v3 1/5] KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR

[Oliver Upton <oupton@kernel.org>]

On Fri, Jun 19, 2026 at 12:07:03AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] KVM injects an External Abort instead of a Permission Fault when a guest accesses a read-only memslot via VNCR with guest stage-1 write protections.
> --
> 
> commit be3537f8a87d3f507b2b54b34084b37b1630155a
> Author: Oliver Upton <oupton@kernel.org>
> KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR
> 
> This commit updates KVM to cache the writability of the PFN in the VNCR
> TLB to constrain the resulting fixmap permissions. It also promotes VNCR
> permission faults to a Synchronous External Abort (SEA) when the guest
> attempts to write to a read-only endpoint.
> 
> Link: https://lore.kernel.org/kvm/20260608082603.16AEC1F00893@smtp.kernel.org/
> 
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 3a5571c3c1142..903ccabca78c5 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> [ ... ]
> > @@ -1401,7 +1402,7 @@ static int kvm_translate_vncr(struct kvm_vcpu *vcpu, bool *is_gmem)
> >  	if (!*is_gmem) {
> >  		pfn = __kvm_faultin_pfn(memslot, gfn, write_fault ? FOLL_WRITE : 0,
> >  					&writable, &page);
> > -		if (is_error_noslot_pfn(pfn) || (write_fault && !writable))
> > +		if (is_error_noslot_pfn(pfn))
> >  			return -EFAULT;
> 
> [Severity: High]
> This is a pre-existing issue, but does this leak host memory configuration
> to the guest by incorrectly prioritizing an External Abort over a Permission
> Fault?
> 
> When a guest takes a VNCR write fault, this code unconditionally requests
> FOLL_WRITE from __kvm_faultin_pfn() without checking if the guest's
> stage-1 page tables actually permit writes (vt->wr.pw).
> 
> If the backing host memslot is read-only, __kvm_faultin_pfn() fails and KVM
> returns -EFAULT, which ultimately causes KVM to inject a guest External Abort
> (ESR_ELx_FSC_EXTABT). Architecturally, if the guest's stage-1 translation
> lacks write permission, the guest should receive a Stage-1 Permission Fault
> regardless of the host's physical memory permissions.
> 
> Could this cause unexpected guest panics if the guest OS relies on handling
> Permission Faults gracefully before the host RO mapping is enforced?

The goal here is to have a localized, stable-worthy fix to plug a nasty
bug that allows the guest to bypass host permissions. A fix for the
fault prioritization can be done later, ideally as part of a more
significant cleanup to the whole VNCR handling.

A guest is far more likely to use normal memory (i.e. in a RW memslot) for the
VNCR page anyway.

Thanks,
Oliver