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