CVE-2025-46723 – openvm

Package

Manager: cargo
Name: openvm
Vulnerable Version: =1.0.0 || >=1.0.0 <1.1.0

Severity

Level: High

CVSS v3.1: CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L/E:P/RL:O/RC:C

CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P

EPSS: 0.00088 pctl0.26083

Details

OpenVM allows the byte decomposition of pc in AUIPC chip to overflow The fix to https://cantina.xyz/code/c486d600-bed0-4fc6-aed1-de759fd29fa2/findings/21 has a typo that still results in the highest limb of `pc` being range checked to 8-bits instead of 6-bits. In the AIR, we do https://github.com/openvm-org/openvm/blob/0f94c8a3dfa7536c1231465d1bdee5fc607a5993/extensions/rv32im/circuit/src/auipc/core.rs#L135 ``` for (i, limb) in pc_limbs.iter().skip(1).enumerate() { if i == pc_limbs.len() - 1 { ``` It should be ``` for (i, limb) in pc_limbs.iter().enumerate().skip(1) { ``` Right now the if statement is never triggered because the enumeration gives `i=0,1,2` when we instead want `i=1,2,3`. What this means is that `pc_limbs[3]` is range checked to 8-bits instead of 6-bits. This leads to a vulnerability where the `pc_limbs` decomposition differs from the true `pc`, which means a malicious prover can make the destination register take a different value than the AUIPC instruction dictates, by making the decomposition overflow the BabyBear field.

Metadata

Created: 2025-05-05T19:57:09Z
Modified: 2025-05-05T19:57:09Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2025/05/GHSA-jf2r-x3j4-23m7/GHSA-jf2r-x3j4-23m7.json
CWE IDs: ["CWE-131"]
Alternative ID: GHSA-jf2r-x3j4-23m7
Finding: F316
Auto approve: 1