Re: [PATCH] riscv: KVM: Add hart-to-vCPU mapping for faster MSI injection

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] Heap out-of-bounds write in `aia_init()` due to unvalidated, user-controlled `hart_index`.
- [High] Heap out-of-bounds read in MSI injection paths due to bounds checking against the dynamically changing `kvm->created_vcpus`.
- [High] Initializing the AIA irqchip when zero vCPUs exist assigns `ZERO_SIZE_PTR` to `hart_to_vcpu`, leading to a fatal page fault on MSI injection.
- [High] Missing memory barrier (data race) when publishing the `kvm->arch.aia.initialized` flag.
--

--- Patch [1]: [PATCH] riscv: KVM: Add hart-to-vCPU mapping for faster MSI injection ---
commit 709e2881a16d8c1738dcbf37e41c35b07a8f7157
Author: BillXiang <xiangwencheng@lanxincomputing.com>

riscv: KVM: Add hart-to-vCPU mapping for faster MSI injection

This patch introduces a direct lookup table to map hart_index to vCPU for
MSI injections, replacing the previous linear scans. The table is allocated
during AIA device initialization based on the number of created vCPUs.

> diff --git a/arch/riscv/kvm/aia_device.c b/arch/riscv/kvm/aia_device.c
> index b195a93add1ce..555157d1db5b0 100644
> --- a/arch/riscv/kvm/aia_device.c
> +++ b/arch/riscv/kvm/aia_device.c
> @@ -249,6 +249,14 @@ static int aia_init(struct kvm *kvm)
>  	if (ret)
>  		return ret;
>  
> +	aia->hart_to_vcpu = kcalloc(kvm->created_vcpus,
> +					sizeof(struct kvm_vcpu*),
> +					GFP_KERNEL);
> +	if (!aia->hart_to_vcpu) {
> +		ret = -ENOMEM;
> +		goto fail_cleanup_aplic;
> +	}
> +

[Severity: High]
If the host userspace initializes the AIA irqchip before creating any vCPUs,
will kcalloc() with a zero count return ZERO_SIZE_PTR?

Because ZERO_SIZE_PTR is not NULL, the allocation check will pass.

Later on, if a vCPU is created and an MSI is injected, could this lead to a
page fault when ZERO_SIZE_PTR is used as a base pointer for the array
in kvm_riscv_aia_inject_msi()?

>  	/* Iterate over each VCPU */
>  	kvm_for_each_vcpu(idx, vcpu, kvm) {
>  		vaia = &vcpu->arch.aia_context;
[ ... ]
> @@ -271,6 +279,12 @@ static int aia_init(struct kvm *kvm)
>  		vaia->hart_index = aia_imsic_hart_index(aia,
>  							vaia->imsic_addr);
>  
> +		if (aia->hart_to_vcpu[vaia->hart_index]) {

[Severity: Critical]
Is vaia->hart_index guaranteed to be within the bounds of the hart_to_vcpu
array?

The hart_index is derived from the user-controlled imsic_addr, nr_hart_bits,
and nr_group_bits via aia_imsic_hart_index().

Since aia->hart_to_vcpu is sized exactly to kvm->created_vcpus, could a
maliciously configured address cause an out-of-bounds read and subsequent
out-of-bounds write when we assign the vcpu pointer to this array?

> +			ret = -EINVAL;
> +			goto fail_cleanup_imsics;
> +		}
> +		aia->hart_to_vcpu[vaia->hart_index] = vcpu;
> +
>  		/* Initialize IMSIC for this VCPU */
>  		ret = kvm_riscv_vcpu_aia_imsic_init(vcpu);

[Severity: High]
Does publishing the aia->hart_to_vcpu array and setting the initialized flag
at the end of aia_init() require a memory barrier?

aia_init() publishes the array and then sets:
    kvm->arch.aia.initialized = true;

Since KVM_SIGNAL_MSI ioctls do not hold kvm->lock, they can run concurrently.

Because RISC-V uses a weakly ordered memory model, could the CPU or compiler
reorder the write to the initialized flag before the array is fully populated?

If a concurrent MSI injection sees initialized == true but reads an
uninitialized aia->hart_to_vcpu array, could this result in a wild pointer
dereference?

[ ... ]
> @@ -541,30 +558,28 @@ void kvm_riscv_vcpu_aia_deinit(struct kvm_vcpu *vcpu)
>  int kvm_riscv_aia_inject_msi_by_id(struct kvm *kvm, u32 hart_index,
>  				   u32 guest_index, u32 iid)
>  {
[ ... ]
> +	if (!aia->hart_to_vcpu || hart_index >= kvm->created_vcpus)
> +		return 0;
>  
> -	return 0;
> +	vcpu = aia->hart_to_vcpu[hart_index];

[Severity: High]
Could this bounds check fail to protect the array access if vCPUs are created
after the AIA device is initialized?

The hart_to_vcpu array is allocated with a capacity equal to
kvm->created_vcpus at the time aia_init() is called.

If additional vCPUs are created via KVM_CREATE_VCPU post-initialization,
kvm->created_vcpus will increase dynamically.

Would injecting an MSI with a hart_index corresponding to a newly added vCPU
bypass this check (since it tests against the newly incremented vCPU count
rather than the array's actual allocation size) and result in an
out-of-bounds read?

> +	if (!vcpu)
> +		return 0;
> +
> +	return kvm_riscv_vcpu_aia_imsic_inject(vcpu, guest_index, 0, iid);
>  }
>  
>  int kvm_riscv_aia_inject_msi(struct kvm *kvm, struct kvm_msi *msi)
>  {
[ ... ]
> +	hart_index = aia_imsic_hart_index(aia, target);
> +	if(hart_index >= kvm->created_vcpus)
> +		return 0;
> +
> +	vcpu = aia->hart_to_vcpu[hart_index];

[Severity: High]
Does the same dynamic kvm->created_vcpus bounds checking regression apply
here in kvm_riscv_aia_inject_msi() as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730093614.983508-1-xiangwencheng@lanxincomputing.com?part=1