Re: [PATCH v2 1/4] KVM: Move last_steal to common struct kvm_vcpu

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Host-userspace reachable WARN_ON can cause a host crash when updating guest steal time.
--

commit 8f2f1662b1b75cda859eddacb4ef288871960d3d
Author: Dongli Zhang <dongli.zhang@oracle.com>

KVM: Move last_steal to common struct kvm_vcpu

This commit moves the last_steal cache field for the per-vCPU host task's
run_delay from architecture-specific structures into the common struct
kvm_vcpu. It updates x86, arm64, riscv, and loongarch to use this unified
field and introduces the HAVE_KVM_PV_STEAL_TIME config option.

[ ... ]

> diff --git a/arch/riscv/kvm/vcpu_sbi_sta.c b/arch/riscv/kvm/vcpu_sbi_sta.c
> index 60e50296a0085..9a77d3bde7c72 100644
> --- a/arch/riscv/kvm/vcpu_sbi_sta.c
> +++ b/arch/riscv/kvm/vcpu_sbi_sta.c
[ ... ]
> @@ -67,8 +67,8 @@ void kvm_riscv_vcpu_record_steal_time(struct kvm_vcpu *vcpu)
>  
>  	if (!WARN_ON(get_user(steal_le, steal_ptr))) {
>  		steal = le64_to_cpu(steal_le);
> -		vcpu->arch.sta.last_steal = READ_ONCE(current->sched_info.run_delay);
> -		steal += vcpu->arch.sta.last_steal - last_steal;
> +		vcpu->last_steal = READ_ONCE(current->sched_info.run_delay);
> +		steal += vcpu->last_steal - last_steal;
>  		WARN_ON(put_user(cpu_to_le64(steal), steal_ptr));
>  	}
>  

[Severity: High]
This is a pre-existing issue, but I noticed these WARN_ON() macros wrapping
get_user() and put_user() accesses to host-userspace memory in 
kvm_riscv_vcpu_record_steal_time() (as well as the sequence_ptr accesses
just above this block).

Could a malicious host-userspace process trigger these kernel warnings by
unmapping the shared memory area or protecting it with mprotect(PROT_NONE)
before this function runs?

If the virtual memory area is made inaccessible, get_user() or put_user()
will fail with -EFAULT, causing the WARN_ON() to fire. This allows
unprivileged host userspace to trigger a host kernel panic if panic_on_warn
is enabled.

Would it be better to handle these user-memory access checks as normal error
paths without the WARN_ON() wrappers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904175550.430266-1-dongli.zhang@oracle.com?part=1