Unbounded loops iterating over _gaugeList in GaugeController.sol and managerList in BoostController.sol and potentially other contracts with similar unbounded array loops can lead to permanent Denial of Service (DoS).
Functions Several contracts, particularly GaugeController.sol and BoostController.sol, use for loops to iterate over arrays (_gaugeList and managerList respectively) that can grow indefinitely over time. These arrays are state variables and do not have any built-in mechanism to shrink or limit their size.
Vulnerable Code Instances
GaugeController.sol.getTotalWeight:
GaugeController.sol.getActiveGauges:
BoostController.sol.updateUserBoost (Indirectly via updateTotalWeight ):Permanent Denial of Service (DoS). As the _gaugeList and managerList arrays grow over time (as more gauges and managers are added), the gas cost of iterating over these arrays in the affected functions will increase linearly. Eventually, the gas cost of calling these functions will exceed the block gas limit, making them unusable and effectively causing a permanent DoS for the contract. This DoS is permanent because there is no mechanism in the current code to shrink these arrays.
Affected Functions (Potentially - Need to Review All Contracts for Unbounded Array Loops):
GaugeController.sol.getTotalWeight
GaugeController.sol.getActiveGauges
GaugeController.sol._distributeToGauges
Potentially other functions in GaugeController.sol and other contracts that iterate over unbounded arrays.
Potentially BoostController.sol.updateUserBoost and functions that call updateTotalWeight if user lists are added in future versions.
Manually reviewed
Immediate Mitigation (Short-Term): Implement size limits on _gaugeList and managerList arrays to prevent unbounded growth and delay DoS. Define MAX_GAUGE_LIST_SIZE, MAX_MANAGER_LIST_SIZE constants and enforce them in array modification functions.
Long-Term Solution (Fundamental Design Change): Re-architect code to avoid unbounded array loops. Use mapping-based aggregation or off-chain calculations for scalable solutions.
Code Review: Identify and refactor all unbounded array loops in critical functions across the codebase.
Testing: Implement multiple tests to simulate array growth and verify gas costs remain within acceptable limits to understand.
Immediate Mitigation (Short-Term): Implement a reasonable limit on the maximum size of _gaugeList and managerList arrays. This will prevent unbounded growth and mitigate the DoS risk in the short term. However, this is not a long-term solution, as the limit could still be reached eventually.
Example Mitigation (Adding Limit to GaugeController.sol.addGauge):
Long-Term Solution (Fundamental Design Change): Re-architect the code to avoid unbounded array loops for critical operations. Consider alternative data structures and algorithmic approaches that do not rely on iterating over potentially very large arrays. Some options include:
Paginated or Chunked Processing: Process array data in smaller, manageable chunks, using pagination or similar techniques to limit the gas cost per transaction.
Mapping-Based Aggregation: Instead of iterating over arrays to calculate aggregates (like totalWeight or activeGaugeCount), maintain running totals or aggregate values in mappings that can be updated incrementally as gauges or managers are added or modified. This avoids the need for full array iterations.
Off-Chain Aggregation/Calculation: Move some of the aggregation or calculation logic off-chain, performing calculations in backend services or client-side applications and only submitting final results to the smart contract.
Code Review: Thoroughly review all contracts for similar unbounded array loops in public or external functions or internal functions called by public/external functions.
Testing: Implement unit tests and integration tests to verify the effectiveness of the chosen mitigation strategy and ensure that the contract remains usable even with a large number of gauges or managers.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.