GHSA-jf2r-x3j4-23m7

Source

https://github.com/advisories/GHSA-jf2r-x3j4-23m7

Import Source

https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2025/05/GHSA-jf2r-x3j4-23m7/GHSA-jf2r-x3j4-23m7.json

JSON Data

https://api.osv.dev/v1/vulns/GHSA-jf2r-x3j4-23m7

Aliases

CVE-2025-46723

Published

2025-05-05T19:57:09Z

Modified

2025-05-05T20:42:09.376504Z

Severity

7.8 (High) CVSS_V4 - 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 CVSS Calculator

Summary

OpenVM allows the byte decomposition of pc in AUIPC chip to overflow

Details

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.

Database specific

{
    "nvd_published_at": "2025-05-02T23:15:16Z",
    "cwe_ids": [
        "CWE-131"
    ],
    "severity": "HIGH",
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-05T19:57:09Z"
}

GHSA-jf2r-x3j4-23m7

Affected packages

crates.io / openvm

Package

Affected ranges

Affected versions

1.*