From: sashiko-bot@kernel.org
To: "Paul White" <paul.white.kernel@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: riscv: Eliminate redundancy in set_reg function via pointers
Date: Mon, 26 Oct 2026 07:02:38 +0000 [thread overview]
Message-ID: <sashiko-outbox-184646@kernel.org> (raw)
In-Reply-To: <073a56efd7e8f5b1e54207f266e1fa972b54a0e2.1792982932.git.paul.white.kernel@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] KVM: riscv: wrong FP register size check in kvm_riscv_vcpu_set_reg_fp()
--
commit 22c4a5d5b5662dbf020a9f9d6d213a5477e96b0d
Author: Paul White <paul.white.kernel@gmail.com>
KVM: riscv: Eliminate redundancy in set_reg function via pointers
This commit refactors kvm_riscv_vcpu_set_reg_fp() to consolidate the register
type and bounds checks for single-precision and double-precision floating
point registers using local pointer and offset variables.
> diff --git a/arch/riscv/kvm/vcpu_fp.c b/arch/riscv/kvm/vcpu_fp.c
> index 16999a5c45dec..fe49576035192 100644
> --- a/arch/riscv/kvm/vcpu_fp.c
> +++ b/arch/riscv/kvm/vcpu_fp.c
> @@ -144,41 +144,53 @@ int kvm_riscv_vcpu_set_reg_fp(struct kvm_vcpu *vcpu,
> struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
> unsigned long __user *uaddr =
> (unsigned long __user *)(unsigned long)reg->addr;
> - unsigned long reg_num = reg->id & ~(KVM_REG_ARCH_MASK |
> + unsigned long token_reg_num = reg->id & ~(KVM_REG_ARCH_MASK |
> KVM_REG_SIZE_MASK |
> rtype);
> void *reg_val;
>
> + u32 *fcsr_addr;
> + void *f_array_addr;
> + size_t byte_offset = 0;
> + unsigned long offical_fcsr_num = 0;
> + unsigned long offical_first_reg = 0;
> + unsigned long offical_last_reg = 0;
> +
> if ((rtype == KVM_REG_RISCV_FP_F) &&
> riscv_isa_extension_available(vcpu->arch.isa, F)) {
> + fcsr_addr = &cntx->fp.f.fcsr;
> + f_array_addr = &cntx->fp.f.f;
> + byte_offset = 4;
> + offical_fcsr_num = KVM_REG_RISCV_FP_F_REG(fcsr);
> + offical_first_reg = KVM_REG_RISCV_FP_F_REG(f[0]);
> + offical_last_reg = KVM_REG_RISCV_FP_F_REG(f[31]);
> + } else if ((rtype == KVM_REG_RISCV_FP_D) &&
> + riscv_isa_extension_available(vcpu->arch.isa, D)) {
> + fcsr_addr = &cntx->fp.d.fcsr;
> + f_array_addr = &cntx->fp.d.f;
> + byte_offset = 8;
> + offical_fcsr_num = KVM_REG_RISCV_FP_D_REG(fcsr);
> + offical_first_reg = KVM_REG_RISCV_FP_D_REG(f[0]);
> + offical_last_reg = KVM_REG_RISCV_FP_D_REG(f[31]);
> + } else {
> + return -ENOENT;
> + }
> +
> + if (token_reg_num == offical_fcsr_num) {
> if (KVM_REG_SIZE(reg->id) != sizeof(u32))
> return -EINVAL;
> - if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
> - reg_val = &cntx->fp.f.fcsr;
> - else if ((KVM_REG_RISCV_FP_F_REG(f[0]) <= reg_num) &&
> - reg_num <= KVM_REG_RISCV_FP_F_REG(f[31])) {
> - reg_num = array_index_nospec(reg_num,
> - ARRAY_SIZE(cntx->fp.f.f));
> - reg_val = &cntx->fp.f.f[reg_num];
> - } else
> - return -ENOENT;
> - } else if ((rtype == KVM_REG_RISCV_FP_D) &&
> - riscv_isa_extension_available(vcpu->arch.isa, D)) {
> - if (reg_num == KVM_REG_RISCV_FP_D_REG(fcsr)) {
> - if (KVM_REG_SIZE(reg->id) != sizeof(u32))
> - return -EINVAL;
> - reg_val = &cntx->fp.d.fcsr;
> - } else if ((KVM_REG_RISCV_FP_D_REG(f[0]) <= reg_num) &&
> - reg_num <= KVM_REG_RISCV_FP_D_REG(f[31])) {
> - if (KVM_REG_SIZE(reg->id) != sizeof(u64))
> - return -EINVAL;
> - reg_num = array_index_nospec(reg_num,
> - ARRAY_SIZE(cntx->fp.d.f));
> - reg_val = &cntx->fp.d.f[reg_num];
> - } else
> - return -ENOENT;
> - } else
> + reg_val = fcsr_addr;
> + } else if ((offical_first_reg <= token_reg_num) && (token_reg_num <= offical_last_reg)) {
> + if ((KVM_REG_SIZE(reg->id) != sizeof(u32)) &&
> + (KVM_REG_SIZE(reg->id) != sizeof(u64))) {
> + return -EINVAL;
> + }
> + token_reg_num = array_index_nospec(token_reg_num,
> + 32);
> + reg_val = (u8 *)f_array_addr + (token_reg_num * byte_offset);
> + } else {
> return -ENOENT;
> + }
>
> if (copy_from_user(reg_val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
[Severity: High]
Can this size check allow an out-of-bounds write to cntx->fp.f.f[] when rtype
is KVM_REG_RISCV_FP_F and userspace passes KVM_REG_SIZE_U64 in reg->id via
KVM_SET_ONE_REG?
Previously, kvm_riscv_vcpu_set_reg_fp() required KVM_REG_SIZE(reg->id) ==
sizeof(u32) for KVM_REG_RISCV_FP_F registers and KVM_REG_SIZE(reg->id) ==
sizeof(u64) for KVM_REG_RISCV_FP_D data registers f[0]..f[31].
With the combined check:
if ((KVM_REG_SIZE(reg->id) != sizeof(u32)) &&
(KVM_REG_SIZE(reg->id) != sizeof(u64))) {
return -EINVAL;
}
an 8-byte size is accepted when rtype is KVM_REG_RISCV_FP_F (where
f_array_addr points to cntx->fp.f.f and byte_offset is 4). The subsequent
copy_from_user(reg_val, uaddr, KVM_REG_SIZE(reg->id)) then writes 8 bytes
into a 4-byte element of cntx->fp.f.f[32], overwriting the adjacent register
cntx->fp.f.f[token_reg_num + 1] or overflowing cntx->fp.f.f[] into
cntx->fp.f.fcsr when token_reg_num is 31.
Conversely, when rtype is KVM_REG_RISCV_FP_D (where byte_offset is 8), a
4-byte size is now accepted for f[0]..f[31] instead of returning -EINVAL,
resulting in a partial 4-byte write to cntx->fp.d.f[token_reg_num].
Note that the same check was also introduced in kvm_riscv_vcpu_get_reg_fp()
earlier in this series, where copy_to_user() can similarly read 8 bytes from
a 4-byte element of cntx->fp.f.f[32].
Should both functions check KVM_REG_SIZE(reg->id) != byte_offset for the data
registers instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1792982932.git.paul.white.kernel@gmail.com?part=2
prev parent reply other threads:[~2026-10-26 7:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 3:41 [PATCH 0/2] KVM: riscv: Unify and optimize FP register loops Paul White
2026-10-26 3:41 ` [PATCH 1/2] KVM: riscv: Eliminate redundancy in get_reg function via pointers Paul White
2026-10-26 7:02 ` sashiko-bot
2026-10-26 3:41 ` [PATCH 2/2] KVM: riscv: Eliminate redundancy in set_reg " Paul White
2026-10-26 7:02 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-184646@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=paul.white.kernel@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox