Re: [PATCH 08/22] KVM: arm64: nv: Treat DBM as writable at stage-2

[Oliver Upton <oupton@kernel.org>]

On Tue, Jun 23, 2026 at 06:55:33PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] DBM incorrectly grants write permission to "No access" stage-2 pages, breaking nested guest isolation.
> --
> 
> commit 99b59d5177f5650f344f4c618e4c4dcd2d5d6d1c
> Author: Oliver Upton <oupton@kernel.org>
> 
> KVM: arm64: nv: Treat DBM as writable at stage-2
> 
> This commit modifies the stage-2 permission computation to treat the DBM bit
> as granting write permission when hardware dirty state is enabled.
> 
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> [ ... ]
> > @@ -305,6 +305,17 @@ static void compute_s2_permissions(struct kvm_vcpu *vcpu, struct s2_walk_info *w
> >  		break;
> >  	}
> >  
> > +	/*
> > +	 * Descriptors with the DBM bit set while hardware dirty state are
> > +	 * considered writable, even though certain accesses (like AT instructions)
> > +	 * don't actually update the dirty state.
> > +	 *
> > +	 * Assume that walk_nestd_s2_pgd() made the necessary descriptor updates
> > +	 * for the access and just treat DBM as writable here.
> > +	 */
> > +	if (wi->hd && ws->desc & KVM_PTE_LEAF_ATTR_HI_S2_DBM)
> > +		s2ap |= BIT(1);
> 
> [Severity: Critical]
> If s2ap is initially 0b00 (No access), this unconditional OR operation will
> upgrade it to 0b10 (Write-only) in compute_s2_permissions(). Does this
> inadvertently bypass stage-2 memory protections if an L1 hypervisor maps a
> page as No access but leaves the DBM bit set?
> 
> Without verifying that read access is already granted via s2ap & BIT(0),
> this logic grants write permission to a No access page, allowing an L2 guest
> to write to memory explicitly protected by the L1 hypervisor.

This is wrong.

R_XZFQH defines a descriptor with DBM set that would otherwise generate
a write permission fault as writable-clean. That means the descriptor
grants write permission and hardware can relax it to writable-dirty
depending on the access.

Thanks,
Oliver