Re: [PATCH v3 1/5] RISC-V: KVM: Add the split page cache for ioctl context

[sashiko-bot@kernel.org]

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

New issues:
- [High] Lockless freeing of `pgd_split_page_cache` in `kvm_riscv_mmu_free_pgd()` introduces a structural data race with concurrent KVM ioctls.

Pre-existing issues:
- [Critical] Guest memory fault after `mmu_notifier_release` causes a host kernel panic due to unchecked NULL pgd.
--

commit 4369101385f8b6b3e99f16d6f89e641a21847559
Author: Wang Yechao <wang.yechao255@zte.com.cn>

RISC-V: KVM: Add the split page cache for ioctl context

This commit adds a split page cache for dirty logging enablement and the
KVM_CLEAR_DIRTY_LOG ioctl on RISC-V.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 082f9b2617338..d69fba7d8e9a6 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c

[ ... ]

> @@ -703,6 +704,8 @@ void kvm_riscv_mmu_free_pgd(struct kvm *kvm)
>  
>  	if (pgd)
>  		free_pages((unsigned long)pgd, get_order(kvm_riscv_gstage_pgd_size));
> +
> +	kvm_mmu_free_memory_cache(&kvm->arch.pgd_split_page_cache);

[Severity: High]
Does freeing this cache locklessly introduce a use-after-free race with
concurrent KVM ioctls?

If mmu_notifier_release() is executed by exit_mmap() while a concurrent
process (sharing the KVM fd) executes KVM_CLEAR_DIRTY_LOG, they can race.

KVM_CLEAR_DIRTY_LOG calls mmu_split_huge_pages(), which drops kvm->mmu_lock
and locklessly tops up the cache:

arch/riscv/kvm/mmu.c:mmu_split_huge_pages() {
    ...
            write_unlock(&kvm->mmu_lock);
            cond_resched();

            ret = kvm_mmu_topup_memory_cache(pcache, count);
    ...
}

Concurrently, kvm_riscv_mmu_free_pgd() (invoked by mmu_notifier_release())
takes and releases kvm->mmu_lock, and then locklessly calls
kvm_mmu_free_memory_cache() here, which can free the cache while it is being
accessed by the top-up.

[Severity: Critical]
This is a pre-existing issue, but does setting kvm->arch.pgd to NULL earlier
in kvm_riscv_mmu_free_pgd() expose a host kernel panic if a guest memory
fault occurs afterward?

If mmu_notifier_release() runs (e.g., via exit_mmap()), it sets
kvm->arch.pgd = NULL. If another process holding the KVM fd subsequently
invokes KVM_RUN, a guest memory fault will enter kvm_riscv_mmu_map() and
eventually kvm_riscv_gstage_get_leaf() without checking if pgd is NULL.

In kvm_riscv_gstage_get_leaf(), the NULL pgd is offset and blindly
dereferenced:

arch/riscv/kvm/gstage.c:kvm_riscv_gstage_get_leaf() {
    ...
        ptep = (pte_t *)gstage->pgd;
        ptep = &ptep[gstage_pte_index(gstage, addr, current_level)];
        while (ptep && pte_val(ptep_get(ptep))) {
    ...
}

Can this lead to a host panic via an unprivileged userspace process?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623121332.78514-1-wang.yechao255@zte.com.cn?part=1