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

[Dongli Zhang]

+ kvm-riscv at lists.infradead.org

The issue reported by sashiko isn't relevant to the patchset.

I don't have risc-v KVM host to reproduce this issue. It looks can be reproduced
on purpose.

Thank you very much!

Dongli Zhang

On Fri, Sep 4, 2026 11:07:15AM -0700, sashiko-bot at kernel.org wrote:
> 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 at 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?
>