[Bug] Panic-Inducing Integer Overflow in `KZG10::load_srs()` of snarkVM (CWE-190)

[zklimaleo]

🐛 Bug Report

(Copied from HackerOne) Integer overflow in the KZG10::load_srs() function that triggers a runtime panic when extremely large input is passed (like usize::MAX). Specifically, this happens on the line https://github.com/ProvableHQ/snarkVM/blob/a87ceb9ccdb7d45d876c7212208b95b5a6b01820/algorithms/src/polycommit/kzg10/mod.rs#L94 when max_degree + 1 overflows.

Expected Behavior

Should handle the overflow risk.

[Oblivionsage]

Integer Overflow in KZG10::load_srs() Causing Panic on Unchecked max_degree

Hi team,

I’m following up on the HackerOne report that was marked [Informative] — adding more technical context and reproduction details here for developer visibility and potential patching

Summary

There is a panic triggered in KZG10::load_srs() due to unchecked addition:

The panic occurs at:

mod.rs:94

params.download_powers_for(0..(max_degree + 1));

If max_degree is set to usize::MAX, this causes a crash due to integer overflow — max_degree + 1 wraps to 0 in release mode and panics in debug.

This is reachable via the public Snark trait through the universal_setup() method and is not just limited to fuzzing

Proof of Reachability

The panic chain is:

• AHPForR1CS::max_degree(num_constraints, num_variables, ...)

• → universal_setup(max_degree)

• → SonicKZG10::load_srs(max_degree)

• → max_degree + 1 causes panic

In several test cases (varuna/tests.rs), max_degree is computed dynamically from user-supplied values like num_constraints, num_variables, etc.

This is reachable via the public Snark trait (defined in (algorithms/src/traits/snark.rs) line 59) , which is still actively used by downstream crates for setup tooling.

#(algorithms/src/traits/snark.rs) line 59
fn universal_setup(config: usize) -> Result<Self::UniversalSRS>;

Real-World Impact

Crashes provers, test runners, and ceremony tooling using universal_setup()

Easily reachable by feeding large inputs in local test environments or setup scripts

Breaks reproducible zkSNARK test chains if circuit inputs aren’t bounded

Reproducible Case

I’ve already shared a fuzz test in the original report. If you want, I can provide a Docker-based CI crash demo.

Thanks again for reviewing this. Let me know if you'd like me to submit a PR with the fix.

Best regards,

@theoblivionsage