Re: [PATCH v5 3/3] RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector

[email protected] Mon, 03 Aug 2026 22:37:41 +0000
Newsgroups org.kernel.vger.kvm
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Preemptible kernel-mode vector (KMV) state is corrupted by KVM pre=
empt notifiers when a VCPU thread is preempted.
--

--- Patch [3]: [PATCH v5 3/3] RISC-V: KVM: fix vcpu vector context handling=
 for kernel-mode vector ---
commit 077b610f9ed223f15b05bd83c13e358e4b341dc9
Author: Andy Chiu <[email protected]>

RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector
   =20
This commit registers an RCU-protected callback to flush the vCPU vector
context when kernel-mode vector (KMV) is serving a guest. This prevents
KMV from misattributing the guest's vCPU context as the user's context.

> diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
> --- a/arch/riscv/kvm/vcpu.c
> +++ b/arch/riscv/kvm/vcpu.c
[ ... ]
> @@ -654,9 +656,11 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  	kvm_riscv_vcpu_host_fp_restore(&vcpu->arch.host_context);
> =20
>  	kvm_riscv_vcpu_timer_save(vcpu);
> +	get_cpu_vector_context();
>  	kvm_riscv_vcpu_guest_vector_save(&vcpu->arch.guest_context,
>  					 vcpu->arch.isa);
>  	kvm_riscv_vcpu_host_vector_restore(&vcpu->arch.host_context);

[Severity: High]
This is a pre-existing issue, but does unconditionally restoring the host=20
vector context here corrupt the kernel-mode vector state if the vCPU thread
is preempted?

If a vCPU thread enters a kernel-mode vector section (like
enter_vector_usercopy() during guest I/O) and is preempted by a page fault,
kvm_sched_out() calls kvm_arch_vcpu_put(). This unconditionally restores the
host (QEMU) vector registers via kvm_riscv_vcpu_host_vector_restore().

When switch_to() subsequently calls __switch_to_vector(), wouldn't it save
this newly clobbered hardware state into the kernel's vector context buffer
(kernel_vstate) instead of the actual kernel vector state?

Could a malicious guest trigger this by supplying an unmapped virtual addre=
ss
for an I/O operation, forcing a page fault and voluntary preemption during
the vector-optimized copy_to_user()?

> +	put_cpu_vector_context();
> =20
>  	if (kvm_riscv_nacl_available()) {
>  		nsh =3D nacl_shmem();

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803215250.8244=
[email protected]?part=3D3