Re: [PATCH 3/6] KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Acquiring `mmu_lock` (an `rwlock_t`) while preemption is disabled causes a sleep-in-atomic bug on PREEMPT_RT kernels.
--

--- Patch [3]: [PATCH 3/6] KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page ---
commit 35765bd8ff67c3b2b00cff5d84e75d6902846a0f
Author: Marc Zyngier <maz@kernel.org>
Subject: KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page

This commit ensures the S1 MMU state is verified against the cached state
in the TLB when mapping the L1 VNCR page. If the cached state does not match
the current MMU state, the mapping is ignored to prevent inconsistent
translations.

[ ... ]

> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index b026d160f253d..711c0d0ff8339 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1579,6 +1579,9 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
>  	if (!vt->valid)
>  		return;

[Severity: High]
This isn't a regression introduced by this patch, but looking at the earlier
lines in kvm_map_l1_vncr():

arch/arm64/kvm/nested.c:kvm_map_l1_vncr() {
    ...
	guard(preempt)();
	guard(read_lock)(&vcpu->kvm->mmu_lock);
    ...
}

I noticed the order of these guards causes preemption to be disabled prior to
acquiring mmu_lock (which is an rwlock_t).

On Preempt-RT kernels, rwlock_t is mapped to an rt_rw_lock which is a
sleepable lock. Does acquiring it while preemption is explicitly disabled
trigger a sleep-in-atomic splat here?

Since this path is reachable by a nested guest's normal operations, could this
allow an untrusted guest to panic the host kernel on a Preempt-RT system?

> +	if (!(vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_M) != s1_mmu_disabled(&vt->wr))
> +		return;
> +
>  	if (read_vncr_el2(vcpu) != vt->gva)
>  		return;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260801124818.366274-1-maz@kernel.org?part=3