[M-1] Unbounded deserialization allows memory exhaustion DoS

[this-vishalsingh]

Context: crates/zk-core/src/store.rs

Description

ProverFlush is Deserialized from untrusted input and contains potentially large FlushView (a RangeSet) plus BitVec fields (adjust and optional MAC proof bits).
The TryFrom validation only checks internal length consistency (commit bits == adjust.len() and prove bits == MAC proof bits), but does not enforce any upper bound on the amount of data that can be allocated during deserialization.

A malicious peer can send an oversized serialized ProverFlush to trigger large allocations (and subsequent processing), causing OOM or severe CPU/memory pressure before the verifier can reject it (e.g., even if VerifierStore::receive_flush later detects a view mismatch).

Impacted code

#[derive(Debug, Serialize, Deserialize)]
#[serde(try_from = "validation::ProverFlushUnchecked")]
pub struct ProverFlush {
    view: FlushView,
    adjust: BitVec,
    mac_proof: Option<(BitVec, Hash)>,
}

impl TryFrom<ProverFlushUnchecked> for ProverFlush {
    type Error = String;

    fn try_from(value: ProverFlushUnchecked) -> Result<Self, Self::Error> {
        let ProverFlushUnchecked { view, adjust, mac_proof } = value;

        if view.commit.len() != adjust.len() {
            return Err("prover sent flush with invalid number of adjustment bits".to_string());
        }

        let mac_proof_bits = match mac_proof {
            Some(ref proof) => proof.0.len(),
            None => 0,
        };

        if view.prove.len() != mac_proof_bits {
            return Err("prover sent flush with invalid number of mac proof bits".to_string());
        }

        Ok(ProverFlush { view, adjust, mac_proof })
    }
}

Recommendation

Enforce strict maximum sizes at the deserialization boundary (e.g., message/frame size limits, bincode/serde size limits) and/or add explicit caps in TryFrom (maximum total committed/proved bits and maximum number of ranges in FlushView) derived from protocol/circuit limits.

Consider avoiding serializing view entirely if both parties can derive it locally, or validate sizes before allocating (custom deserializer/visitor).