[v2] target/riscv/pmp: Fix integer overflow in TOR and NA4 address computation

[PATCH v2] target/riscv/pmp: Fix integer overflow in TOR and NA4 address computation

Zishun Yi posted 1 patch 2 weeks, 5 days ago

Diff against v1 v2
Download mbox

Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260511072126.3009004-1-vulab@iscas.ac.cn

Maintainers: Palmer Dabbelt <palmer@dabbelt.com>, Alistair Francis <alistair.francis@wdc.com>, Weiwei Li <liwei1518@gmail.com>, Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, Chao Liu <chao.liu.zevorn@gmail.com>

There is a newer version of this series

target/riscv/pmp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Expand all Fold all

[PATCH v2] target/riscv/pmp: Fix integer overflow in TOR and NA4 address computation

Posted by Zishun Yi 2 weeks, 5 days ago

According to the RISC-V Privileged Manual: "The Sv32 page-based
virtual-memory scheme described in sv32 supports 34-bit physical
addresses for RV32, so the PMP scheme must support addresses wider than
XLEN for RV32."

However, the current QEMU implementation uses `target_ulong` (which
resolves to `uint32_t` on RV32) for PMP address variables.  When
shifting these addresses left (e.g., `this_addr << 2`), an integer
overflow occurs, truncating the high bits of the 34-bit physical
address.

Fix this issue by casting the `target_ulong` variables to `hwaddr`
before performing the left shift operation.

This issue was discovered and reported by SpecHunter, an AI-driven
architecture specification analysis tool.

Link: https://github.com/yizishun/rv-isa-sec/blob/master/output/riscv-isa-manual/pr-2472/qemu.txt
Signed-off-by: Zishun Yi <vulab@iscas.ac.cn>
---
v2: add a missing space after the Link tag clon

 target/riscv/pmp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index 5391caa59c7d..dfddafcbcb48 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -253,12 +253,12 @@ void pmp_update_rule_addr(CPURISCVState *env, uint32_t pmp_index)
             sa = ea = 0u;
             break;
         }
-        sa = prev_addr << 2; /* shift up from [xx:0] to [xx+2:2] */
-        ea = (this_addr << 2) - 1u;
+        sa = (hwaddr)prev_addr << 2; /* shift up from [xx:0] to [xx+2:2] */
+        ea = ((hwaddr)this_addr << 2) - 1u;
         break;
 
     case PMP_AMATCH_NA4:
-        sa = this_addr << 2; /* shift up from [xx:0] to [xx+2:2] */
+        sa = (hwaddr)this_addr << 2; /* shift up from [xx:0] to [xx+2:2] */
         ea = (sa + 4u) - 1u;
         break;
 
-- 
2.51.2

Re: [PATCH v2] target/riscv/pmp: Fix integer overflow in TOR and NA4 address computation

Posted by Alistair Francis 1 week, 5 days ago

On Mon, May 11, 2026 at 7:53 PM Zishun Yi <vulab@iscas.ac.cn> wrote:
>
> According to the RISC-V Privileged Manual: "The Sv32 page-based
> virtual-memory scheme described in sv32 supports 34-bit physical
> addresses for RV32, so the PMP scheme must support addresses wider than
> XLEN for RV32."
>
> However, the current QEMU implementation uses `target_ulong` (which
> resolves to `uint32_t` on RV32) for PMP address variables.  When
> shifting these addresses left (e.g., `this_addr << 2`), an integer
> overflow occurs, truncating the high bits of the 34-bit physical
> address.
>
> Fix this issue by casting the `target_ulong` variables to `hwaddr`
> before performing the left shift operation.

It's probably a better idea to just use `hwaddr` for `this_addr` and
`prev_addr` instead

Alistair