From: sashiko-bot@kernel.org
To: "Wang Yechao" <wang.yechao255@zte.com.cn>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] RISC-V: KVM: Fix out-of-bounds index into aia_irq2bitpos[]
Date: Tue, 27 Oct 2026 11:50:41 +0000 [thread overview]
Message-ID: <sashiko-outbox-186480@kernel.org> (raw)
In-Reply-To: <20261027114439.699273-1-wang.yechao255@zte.com.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] riscv: kvm: dead bounds check in aia_get_iprio8() and aia_set_iprio8()
--
commit c874cd5cc69d874febde23d82ec7ecdefc1600f2
Author: Wang Yechao <wang.yechao255@zte.com.cn>
RISC-V: KVM: Fix out-of-bounds index into aia_irq2bitpos[]
This commit adds bounds checks against ARRAY_SIZE(aia_irq2bitpos) in
aia_get_iprio8() and aia_set_iprio8() to prevent an alleged out-of-bounds
array access when emulating per-HART AIA priority registers on RV64.
> RISC-V: KVM: Fix out-of-bounds index into aia_irq2bitpos[]
>
> aia_get_iprio8() and aia_set_iprio8() index the 64-entry
> aia_irq2bitpos[] array with an irq value derived from the
> guest-controlled VSISELECT register. For RV64:
>
> first_irq = (isel - ISELECT_IPRIO0) * 4
> nirqs = 8
> isel up to ISELECT_IPRIO15
>
> so the irq number can reach 67 and aia_irq2bitpos[64..67] is
> accessed out of bounds. A malicious guest can trigger this,
> causing host panic under KASAN/UBSAN or undefined behavior
> otherwise.
>
> Add an explicit bounds check in both accessors before indexing
> the table.
>
> Fixes: 2f4d58f7635a ("RISC-V: KVM: Virtualize per-HART AIA CSRs")
> Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn>
>
> diff --git a/arch/riscv/kvm/aia.c b/arch/riscv/kvm/aia.c
> index b3b466e4db337..a51d2db7f3311 100644
> --- a/arch/riscv/kvm/aia.c
> +++ b/arch/riscv/kvm/aia.c
> @@ -286,8 +286,12 @@ static int aia_irq2bitpos[] = {
> static u8 aia_get_iprio8(struct kvm_vcpu *vcpu, unsigned int irq)
> {
> unsigned long hviprio;
> - int bitpos = aia_irq2bitpos[irq];
> + int bitpos;
>
> + if (irq >= ARRAY_SIZE(aia_irq2bitpos))
> + return 0;
> +
> + bitpos = aia_irq2bitpos[irq];
> if (bitpos < 0)
> return 0;
>
> @@ -319,8 +323,12 @@ static u8 aia_get_iprio8(struct kvm_vcpu *vcpu, unsigned int irq)
> static void aia_set_iprio8(struct kvm_vcpu *vcpu, unsigned int irq, u8 prio)
> {
> unsigned long hviprio;
> - int bitpos = aia_irq2bitpos[irq];
> + int bitpos;
> +
> + if (irq >= ARRAY_SIZE(aia_irq2bitpos))
> + return;
[Severity: Medium]
Can irq actually reach 64..67 in aia_get_iprio8() or aia_set_iprio8()?
Both helpers are static and only called from aia_rmw_iprio() via
kvm_riscv_vcpu_aia_rmw_ireg() when isel is between ISELECT_IPRIO0 (0x30) and
ISELECT_IPRIO15 (0x3f).
In arch/riscv/kvm/aia.c, aia_rmw_iprio() rejects odd isel values on RV64
before computing first_irq:
arch/riscv/kvm/aia.c:aia_rmw_iprio() {
#ifndef CONFIG_32BIT
if (isel & 0x1)
return KVM_INSN_ILLEGAL_TRAP;
#endif
nirqs = 4 * (BITS_PER_LONG / 32);
first_irq = (isel - ISELECT_IPRIO0) * 4;
...
}
Because ISELECT_IPRIO15 (0x3f) is odd, it returns KVM_INSN_ILLEGAL_TRAP on
RV64. The largest even isel reaching the loop on RV64 is ISELECT_IPRIO14
(0x3e), which gives first_irq = (0x3e - 0x30) * 4 = 56 and nirqs = 8, so
first_irq + i is at most 56 + 7 = 63. On RV32, isel can be ISELECT_IPRIO15
(0x3f), which gives first_irq = 60 and nirqs = 4, so first_irq + i is also
at most 60 + 3 = 63.
Since ARRAY_SIZE(aia_irq2bitpos) is 64, isn't irq already guaranteed to be
in 0..63, making these bounds checks unreachable?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261027114439.699273-1-wang.yechao255@zte.com.cn?part=1
next prev parent reply other threads:[~2026-10-27 11:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 11:44 [PATCH] RISC-V: KVM: Fix out-of-bounds index into aia_irq2bitpos[] Wang Yechao
2026-10-27 11:50 ` sashiko-bot [this message]
2026-10-27 12:02 ` Wang Yechao
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-186480@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wang.yechao255@zte.com.cn \
/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