[Bug] Out of memory (OOM) panic in ProvingKey::<Testnet3>::read_le

[pventuzelo]

Out of memory (OOM) panic in ProvingKey::<Testnet3>::read_le

​
Author(s): @Fuzzinglabs
Date: 20/11/2023
​

Executive Summary

We (@FuzzingLabs) found an Out of memory (OOM) crash while using ProvingKey::<Testnet3>::read_le
​

Vulnerability Details

• Affected Component: snarkVM

Environment

• snarkVM Version: v0.16.10
  ​

Steps to Reproduce

use snarkvm::prelude::*;
pub type Network = Testnet3;
​
​
fn main() {
    let data: &[u8] = &[1, 60, 48, 0, 55, 57, 50, 0, 255, 255, 255, 255, 255, 255, 255, 7, 0, 0, 0, 0, 55, 57, 50, 0, 255, 255, 255, 255, 255, 255, 255, 7, 0, 0, 0, 0, 0, 247, 223, 229, 0, 0, 0, 0, 0, 124, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 40, 40, 32, 0, 0, 0, 40, 40, 40, 0, 45, 0, 53, 56, 53, 0, 1, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 40, 40, 64, 171, 0, 0, 0, 0, 0, 0, 0, 0, 45, 0, 0, 0, 0, 0, 0, 62, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 0, 0, 0, 67, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 1];
    let _ = ProvingKey::<Network>::read_le(data);
}

​

Root Cause Analysis

This line of code tries to create a vector too big (1 << log_size - 1)
​
https://github.com/AleoHQ/snarkVM/blob/c620cc4a89bcd81e9de07e827886a2a57e4375e6/algorithms/src/fft/domain.rs#L611C12-L611C12
​

Detailed Behavior

__GI_raise (@raise:45)
__GI_abort (@abort:66)
std::sys::unix::abort_internal (@std::sys::unix::abort_internal:5)
std::process::abort (@std::process::abort:5)
std::alloc::rust_oom (@std::alloc::rust_oom:10)
__rg_oom (@__rg_oom:8)
alloc::alloc::handle_alloc_error::rt_error (@alloc::alloc::handle_alloc_error::rt_error:8)
alloc::alloc::handle_alloc_error (@alloc::alloc::handle_alloc_error:5)
alloc::raw_vec::RawVec<T,A>::allocate_in (@alloc::raw_vec::RawVec<T,A>::allocate_in:121)
alloc::raw_vec::RawVec<T,A>::with_capacity_in (@<T as alloc::vec::spec_from_elem::SpecFromElem>::from_elem:15)
alloc::vec::Vec<T,A>::with_capacity_in (@<T as alloc::vec::spec_from_elem::SpecFromElem>::from_elem:12)
<T as alloc::vec::spec_from_elem::SpecFromElem>::from_elem (@<T as alloc::vec::spec_from_elem::SpecFromElem>::from_elem:12)
alloc::vec::from_elem (@alloc::vec::from_elem:8)
snarkvm_algorithms::fft::domain::EvaluationDomain<F>::roots_of_unity (/home/user/snarkVM_untouched/algorithms/src/fft/domain.rs:611)
snarkvm_algorithms::fft::domain::EvaluationDomain<F>::precompute_fft::{{closure}} (/home/user/snarkVM_untouched/algorithms/src/fft/domain.rs:361)
snarkvm_utilities::parallel::execute_with_max_available_threads (/home/user/snarkVM_untouched/utilities/src/parallel.rs:76)
snarkvm_algorithms::fft::domain::EvaluationDomain<F>::precompute_fft (/home/user/snarkVM_untouched/algorithms/src/fft/domain.rs:360)
snarkvm_algorithms::snark::varuna::ahp::ahp::AHPForR1CS<F,SM>::fft_precomputation (/home/user/snarkVM_untouched/algorithms/src/snark/varuna/ahp/ahp.rs:152)
<snarkvm_algorithms::snark::varuna::ahp::indexer::circuit::Circuit<F,SM> as snarkvm_utilities::serialize::traits::CanonicalDeserialize>::deserialize_with_mode (/home/user/snarkVM_untouched/algorithms/src/snark/varuna/ahp/indexer/circuit.rs:207)
snarkvm_utilities::serialize::impls::<impl snarkvm_utilities::serialize::traits::CanonicalDeserialize for alloc::sync::Arc<T>>::deserialize_with_mode (/home/user/snarkVM_untouched/utilities/src/serialize/impls.rs:344)
snarkvm_utilities::serialize::traits::CanonicalDeserialize::deserialize_compressed (/home/user/snarkVM_untouched/utilities/src/serialize/traits.rs:161)
<snarkvm_algorithms::snark::varuna::data_structures::circuit_proving_key::CircuitProvingKey<E,SM> as snarkvm_utilities::bytes::FromBytes>::read_le (/home/user/snarkVM_untouched/algorithms/src/snark/varuna/data_structures/circuit_proving_key.rs:55)
snarkvm_synthesizer_snark::proving_key::bytes::<impl snarkvm_utilities::bytes::FromBytes for snarkvm_synthesizer_snark::proving_key::ProvingKey<N>>::read_le (/home/user/snarkVM_untouched/synthesizer/snark/src/proving_key/bytes.rs:27)
bytes_ProvingKey_read_le_reprod::main (/home/user/new_snarkVM_harnesses/src/bin/bytes_ProvingKey_read_le_reprod.rs:7)
core::ops::function::FnOnce::call_once (@core::ops::function::FnOnce::call_once:6)
std::sys_common::backtrace::__rust_begin_short_backtrace (@std::sys_common::backtrace::__rust_begin_short_backtrace:6)
std::rt::lang_start::{{closure}} (@std::rt::lang_start::{{closure}}:7)
core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once (@std::rt::lang_start_internal:235)
std::panicking::try::do_call (@std::rt::lang_start_internal:232)
std::panicking::try (@std::rt::lang_start_internal:232)
std::panic::catch_unwind (@std::rt::lang_start_internal:232)
std::rt::lang_start_internal::{{closure}} (@std::rt::lang_start_internal:232)
std::panicking::try::do_call (@std::rt::lang_start_internal:232)
std::panicking::try (@std::rt::lang_start_internal:232)
std::panic::catch_unwind (@std::rt::lang_start_internal:232)
std::rt::lang_start_internal (@std::rt::lang_start_internal:232)
std::rt::lang_start (@std::rt::lang_start:16)
main (@main:11)
__libc_start_main (@__libc_start_main:64)
_start (@_start:15)

​

Recommendations

Sanitize the input to avoid having a too big log_size

[ljedrz]

Sanitize the input to avoid having a too big log_size

I agree, I don't see a way of going around this here 👍.