Brave Scarlet Flamingo - Array Length Validation Causes Service Denial

[sherlock-admin2]

Brave Scarlet Flamingo

Medium

Array Length Validation Causes Service Denial

Summary

Missing proper error handling will cause a complete service outage for all users as any user will submit mismatched input arrays causing the entire proof generation system to crash.

Root Cause

viewcalls::get_proof_data_exec, viewcalls::get_proof_data_env and viewcalls::get_proof_data_input uses e assert_eq! statements that panic instead of returning errors for input validation.

https://github.com/sherlock-audit/2025-07-malda/blob/main/malda-zk-coprocessor/malda_rs/src/viewcalls.rs#L433-L451

https://github.com/sherlock-audit/2025-07-malda/blob/main/malda-zk-coprocessor/malda_rs/src/viewcalls.rs#L521-L531

https://github.com/sherlock-audit/2025-07-malda/blob/main/malda-zk-coprocessor/malda_rs/src/viewcalls.rs#L597-L607

Internal Pre-conditions

1. Service needs to be running and accepting proof generation requests
2. At least one user needs to have access to call the proof generation functions

External Pre-conditions

None

Attack Path

1. Attacker calls get_proof_data_exec() with mismatched array lengths (e.g., 3 users but 2 markets)
2. Function reaches assert_eq!(users.len(), markets.len()) validation
3. Assertion fails and triggers a panic, crashing the entire service
4. All subsequent proof generation requests fail until service is manually restarted

Impact

All users cannot generate proofs or execute cross-chain operations until the service is manually restarted. The protocol suffers complete downtime from a single malformed request.

PoC

No response

Mitigation

Replace assert_eq! statements with proper error handling that returns Result::Err instead of panicking, allowing the service to reject invalid requests while continuing to serve valid ones.