GHSA-fj2x-735w-74vq: gnark-crypto allows unchecked memory allocation during vector deserialization

The issue has been reported by @raefko from @fuzzinglabs. Excerpts from the report:

A critical vulnerability exists in the gnark-crypto library’s Vector.ReadFrom() function that allows an attacker to trigger arbitrary memory allocation by crafting malicious input data. An attacker can cause the verifier to attempt allocating up to 128 GB of memory with a minimal malicious input, leading to out-of-memory crashes and denial of service.

<strong>Root Cause</strong>

The vulnerability stems from unchecked deserialization of attacker-controlled length fields in the gnark-crypto library’s Vector.ReadFrom() function. The function reads a 4-byte unsigned integer from untrusted input and directly uses it to allocate memory without any validation or bounds checking.

<strong>Vulnerable Code Path</strong>

User Input (Malicious Proof/Data)
         ↓
gnark Proof/Data Deserialization
         ↓
Vector.ReadFrom() (ecc/bn254/fr/vector.go:136-144)
  → sliceLen := binary.BigEndian.Uint32(buf[:4])   // ← ATTACKER-CONTROLLED
  → (*vector) = make(Vector, sliceLen)             // ← UNCHECKED ALLOCATION
         ↓
runtime.makeslice attempts 100+ GB allocation
         ↓
fatal error: runtime: out of memory → SIGABRT

<strong>Vulnerable Code</strong>

File: gnark-crypto@v0.14.0+/ecc/bn254/fr/vector.go:136-144

The code reads a 4-byte big-endian unsigned integer (sliceLen) directly from the input stream and uses it to allocate a slice without any bounds checking or validation. Each element is 32 bytes (fr.Element for BN254 curve), so an attacker can request up to:

Maximum Allocation: 2^32 elements × 32 bytes = 137,438,953,472 bytes ≈ 128 GB

<strong>Root Cause Analysis</strong>

The gnark-crypto library implements a generic serialization format for field element vectors. The format is:

[4 bytes: length (n)] [n × 32 bytes: elements]

The deserialization code trusts the length field implicitly without any validation. This is a classic integer-to-allocation vulnerability pattern, similar to issues that have affected many serialization libraries over the years.