[PATCH] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

[PATCH] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

[Xie Bo]

KVM device ioctls are not serialized against KVM_RUN. As a result,
kvm_riscv_aia_imsic_rw_attr() can snapshot the physical CPU and HGEI of
an IMSIC VS-file before a concurrent vCPU migration releases it.

The HGEI can then be allocated to another vCPU before imsic_vsfile_rw()
uses the stale tuple. A GET or SET attribute may consequently access the
new owner's interrupt file.

Serialize the entire IMSIC attribute operation with the target vCPU
mutex. This prevents the VS-file from being migrated and recycled until
the attribute access completes.

Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC")
Cc: stable@vger.kernel.org
Signed-off-by: Xie Bo <xb@ultrarisc.com>
---
 arch/riscv/kvm/aia_imsic.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
index d38f5de08..2a4f88efe 100644
--- a/arch/riscv/kvm/aia_imsic.c
+++ b/arch/riscv/kvm/aia_imsic.c
@@ -969,9 +969,13 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
 	if (!vcpu)
 		return -ENODEV;
 
+	mutex_lock(&vcpu->mutex);
+
 	imsic = vcpu->arch.aia_context.imsic_state;
-	if (!imsic)
-		return -ENODEV;
+	if (!imsic) {
+		rc = -ENODEV;
+		goto out_unlock;
+	}
 	isel = KVM_DEV_RISCV_AIA_IMSIC_GET_ISEL(type);
 
 	read_lock_irqsave(&imsic->vsfile_lock, flags);
@@ -995,6 +999,8 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
 		rc = imsic_vsfile_rw(vsfile_hgei, vsfile_cpu, imsic->nr_eix,
 				     isel, write, val);
 
+out_unlock:
+	mutex_unlock(&vcpu->mutex);
 	return rc;
 }
 
-- 
2.54.0

Re: [PATCH] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

[sashiko-bot]

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

New issues:
- [High] Uninterruptible `mutex_lock` in device ioctl causes unkillable task hang.

Pre-existing issues:
- [High] Hardware state corruption due to missing CPU check in `kvm_riscv_vcpu_aia_imsic_put()`.
--

--- Patch [1]: [PATCH] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration ---
commit 477c5bd7ef196223bb86313755b20f69e286864b
Author: Xie Bo <xb@ultrarisc.com>
RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

KVM device ioctls are not serialized against KVM_RUN. This patch serializes
the entire IMSIC attribute operation with the target vCPU mutex to prevent
the VS-file from being migrated and recycled until the attribute access
completes.

> diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
> index d38f5de0834c5..2a4f88efee17f 100644
> --- a/arch/riscv/kvm/aia_imsic.c
> +++ b/arch/riscv/kvm/aia_imsic.c
> @@ -969,9 +969,13 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
>  	if (!vcpu)
>  		return -ENODEV;
>  
> +	mutex_lock(&vcpu->mutex);

[Severity: High]
Does this uninterruptible mutex_lock() cause an unkillable task hang if the
target vCPU is currently executing a guest via KVM_RUN and holding its
vcpu->mutex?

Since it is reachable by userspace via KVM_SET_DEVICE_ATTR or
KVM_GET_DEVICE_ATTR, could a user program racing with KVM_RUN block
indefinitely in D-state?

Should this use mutex_lock_killable() instead to prevent a local denial
of service that triggers the hung task watchdog?

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but looking at
kvm_riscv_vcpu_aia_imsic_put(), does it blindly set CSR_HGEIE on the local
CPU without verifying that imsic->vsfile_cpu matches the current
smp_processor_id()?

arch/riscv/kvm/aia_imsic.c:kvm_riscv_vcpu_aia_imsic_put() {
    ...
    if (imsic->vsfile_cpu > -1)
        csr_set(CSR_HGEIE, BIT(imsic->vsfile_hgei));
    ...
}

If a vCPU blocks in kvm_vcpu_block(), it can be migrated to a different CPU
upon wakeup. If it loops and sleeps again without returning to KVM_RUN
(where imsic->vsfile_cpu is updated), kvm_sched_out() will be invoked on the
new CPU.

Could this call kvm_riscv_vcpu_aia_imsic_put() and write to CSR_HGEIE on the
new CPU using imsic->vsfile_hgei allocated for the old CPU, resulting in
cross-CPU hardware state corruption affecting interrupts of other KVM guests?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721073612.137259-1-xb@ultrarisc.com?part=1

Re: [PATCH] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

[Anup Patel]

On Tue, Jul 21, 2026 at 1:06 PM Xie Bo <xb@ultrarisc.com> wrote:
>
> KVM device ioctls are not serialized against KVM_RUN. As a result,
> kvm_riscv_aia_imsic_rw_attr() can snapshot the physical CPU and HGEI of
> an IMSIC VS-file before a concurrent vCPU migration releases it.
>
> The HGEI can then be allocated to another vCPU before imsic_vsfile_rw()
> uses the stale tuple. A GET or SET attribute may consequently access the
> new owner's interrupt file.
>
> Serialize the entire IMSIC attribute operation with the target vCPU
> mutex. This prevents the VS-file from being migrated and recycled until
> the attribute access completes.
>
> Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xie Bo <xb@ultrarisc.com>

Please address the new issue reported by Sashiko bot

Regards,
Anup

> ---
>  arch/riscv/kvm/aia_imsic.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
> index d38f5de08..2a4f88efe 100644
> --- a/arch/riscv/kvm/aia_imsic.c
> +++ b/arch/riscv/kvm/aia_imsic.c
> @@ -969,9 +969,13 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
>         if (!vcpu)
>                 return -ENODEV;
>
> +       mutex_lock(&vcpu->mutex);
> +
>         imsic = vcpu->arch.aia_context.imsic_state;
> -       if (!imsic)
> -               return -ENODEV;
> +       if (!imsic) {
> +               rc = -ENODEV;
> +               goto out_unlock;
> +       }
>         isel = KVM_DEV_RISCV_AIA_IMSIC_GET_ISEL(type);
>
>         read_lock_irqsave(&imsic->vsfile_lock, flags);
> @@ -995,6 +999,8 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
>                 rc = imsic_vsfile_rw(vsfile_hgei, vsfile_cpu, imsic->nr_eix,
>                                      isel, write, val);
>
> +out_unlock:
> +       mutex_unlock(&vcpu->mutex);
>         return rc;
>  }
>
> --
> 2.54.0
>

[PATCH v2] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

[Xie Bo via B4 Relay]

From: Xie Bo <xb@ultrarisc.com>

KVM device ioctls are not serialized against KVM_RUN. As a result,
kvm_riscv_aia_imsic_rw_attr() can snapshot the physical CPU and HGEI of
an IMSIC VS-file before a concurrent vCPU migration releases it.

The HGEI can then be allocated to another vCPU before imsic_vsfile_rw()
uses the stale tuple. A GET or SET attribute may consequently access the
new owner's interrupt file.

Serialize the entire IMSIC attribute operation with the target vCPU
mutex. This prevents the VS-file from being migrated and recycled until
the attribute access completes. Acquire the mutex killably so that the
device ioctl remains interruptible while waiting for KVM_RUN to finish.

Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC")
Cc: stable@vger.kernel.org
Signed-off-by: Xie Bo <xb@ultrarisc.com>
---
Changes in v2:
- Use mutex_lock_killable() and return -EINTR when interrupted.

Link: https://lore.kernel.org/r/20260721073612.137259-1-xb@ultrarisc.com
---
 arch/riscv/kvm/aia_imsic.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
index d38f5de08..74f520e57 100644
--- a/arch/riscv/kvm/aia_imsic.c
+++ b/arch/riscv/kvm/aia_imsic.c
@@ -969,9 +969,14 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
 	if (!vcpu)
 		return -ENODEV;
 
+	if (mutex_lock_killable(&vcpu->mutex))
+		return -EINTR;
+
 	imsic = vcpu->arch.aia_context.imsic_state;
-	if (!imsic)
-		return -ENODEV;
+	if (!imsic) {
+		rc = -ENODEV;
+		goto out_unlock;
+	}
 	isel = KVM_DEV_RISCV_AIA_IMSIC_GET_ISEL(type);
 
 	read_lock_irqsave(&imsic->vsfile_lock, flags);
@@ -995,6 +1000,8 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
 		rc = imsic_vsfile_rw(vsfile_hgei, vsfile_cpu, imsic->nr_eix,
 				     isel, write, val);
 
+out_unlock:
+	mutex_unlock(&vcpu->mutex);
 	return rc;
 }
 

---
base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
change-id: 20260810-imsic-attr-race-06772a04450e

Best regards,
-- 
Xie Bo <xb@ultrarisc.com>

Re: [PATCH v2] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

[sashiko-bot]

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

Pre-existing issues:
- [High] Silent loss of attribute writes due to un-serialized CPU hot-unplug. The patch relies on `vcpu->mutex` to protect the VS-file, but `kvm_riscv_aia_disable()` bypasses this mutex during CPU offline.
--

--- Patch [1]: [PATCH v2] RISC-V: KVM: Serialize IMSIC attributes with vCPU migration ---
commit 27600b866db246ae439be14c51b6bb1e480a817e
Author: Xie Bo <xb@ultrarisc.com>

RISC-V: KVM: Serialize IMSIC attributes with vCPU migration

This commit serializes KVM device ioctls for IMSIC attributes against
KVM_RUN by acquiring the target vCPU mutex in kvm_riscv_aia_imsic_rw_attr().
This aims to prevent the VS-file from being migrated and recycled while
the attribute is being accessed.

Link: https://lore.kernel.org/r/20260721073612.137259-1-xb@ultrarisc.com

> diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
> --- a/arch/riscv/kvm/aia_imsic.c
> +++ b/arch/riscv/kvm/aia_imsic.c

[ ... ]

> @@ -995,6 +1000,8 @@ int kvm_riscv_aia_imsic_rw_attr(struct kvm *kvm, unsigned long type,
>  		rc = imsic_vsfile_rw(vsfile_hgei, vsfile_cpu, imsic->nr_eix,
>  				     isel, write, val);

[Severity: High]
This is a pre-existing issue, but does relying on vcpu->mutex here leave a
race window with CPU hot-unplug?

If a concurrent KVM_SET_DEVICE_ATTR resolves the hardware HGEI and drops
imsic->vsfile_lock, couldn't a simultaneous CPU hot-unplug event cause
kvm_riscv_aia_disable() to run on the offlining CPU?

Looking at the CPU offline path in arch/riscv/kvm/aia.c:

kvm_riscv_aia_disable() {
    ...
    /* Notify IMSIC */
    kvm_riscv_vcpu_aia_imsic_release(vcpu);
    ...
}

This bypasses vcpu->mutex, locklessly flushes the vCPU's HGEI to the SW
file, and frees the HGEI.

If that happens before the IPI is sent in imsic_vsfile_rw(), would we end up
modifying the freed hardware HGEI instead of the SW file, or failing to send
the IPI entirely if the CPU goes fully offline?

Could this result in silently losing attribute updates during live migration?

> +out_unlock:
> +	mutex_unlock(&vcpu->mutex);
>  	return rc;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-imsic-attr-race-v2-1-00ed95ad321e@ultrarisc.com?part=1