Re: [PATCH] RISC-V: KVM: Reject overlapping AIA IMSIC address fields

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Cross-VM state corruption via TOCTOU in KVM_DEV_RISCV_AIA_GRP_IMSIC device attribute handling.
--

--- Patch [1]: [PATCH] RISC-V: KVM: Reject overlapping AIA IMSIC address fields ---
commit 0b0c0711466532b5918ed0373b83ed94930f6c86
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>

RISC-V: KVM: Reject overlapping AIA IMSIC address fields

This commit fixes an issue where overlapping IMSIC configuration fields could
give a single address bit two different meanings. It adds a check during
initialization to reject group-index layouts that overlap with the guest and
HART index bits.

> diff --git a/arch/riscv/kvm/aia_device.c b/arch/riscv/kvm/aia_device.c
> index b195a93add1ce..d0262ed3c0225 100644
> --- a/arch/riscv/kvm/aia_device.c
> +++ b/arch/riscv/kvm/aia_device.c
> @@ -244,6 +244,12 @@ static int aia_init(struct kvm *kvm)
>  	if (aia->nr_sources && aia->aplic_addr == KVM_RISCV_AIA_UNDEF_ADDR)
>  		return -EINVAL;
>  
> +	/* Group index bits must not overlap guest and HART index bits. */
> +	if (aia->nr_group_bits &&
> +	    aia->nr_group_shift < IMSIC_MMIO_PAGE_SHIFT +
> +					  aia->nr_guest_bits + aia->nr_hart_bits)
> +		return -EINVAL;
> +

[Severity: High]
This is a pre-existing issue, but is there a race window here that could
corrupt cross-VM state?

Looking at kvm_riscv_aia_imsic_rw_attr() in arch/riscv/kvm/aia_imsic.c, the
vsfile_lock is dropped before the IPI is sent:

	read_unlock_irqrestore(&imsic->vsfile_lock, flags);

	if (!rc && vsfile_cpu >= 0)
		rc = imsic_vsfile_rw(vsfile_hgei, vsfile_cpu, imsic->nr_eix,
				     isel, write, val);

If the target VCPU migrates to another physical CPU concurrently, could the
VCPU thread executing kvm_riscv_vcpu_aia_imsic_update() free the vsfile_hgei
and reassign it to a different VM?

A delayed IPI from imsic_vsfile_rw() would then execute on the original CPU
in imsic_vsfile_local_rw():

	new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT;
	csr_write(CSR_HSTATUS, new_hstatus);

Does this locally modify the hardware state without verifying if the target
VCPU still owns it?

>  	/* Initialize APLIC */
>  	ret = kvm_riscv_aia_aplic_init(kvm);
>  	if (ret)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718040000.005.6ede2881-caplitmus-rv@iscas.ac.cn?part=1