Liquid Staking

Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Submission Details
Severity: high
Invalid

Unbounded Loop in `LSTRewardsSplitterController::performUpKeep` leads to potential DoS

Summary

The LSTRewardsSplitterController contract contains an unbounded loop in its checkUpkeep and performUpkeep functions. As the number of reward splitters increases, these functions may exceed the block gas limit or become too expensive to call. It is generally not a good practice to loop through an unbounded loop.

Vulnerability Details

The checkUpKeep function retuns a bytes variable representing an array of booleans, whether to call performUpKeep on the given splitter or not. However the checkUpKeep function iterates through all of the splitters that are in the storage array accounts and mapping splitters. This number could grow to a number that is too big either hiting the block gas limit or causing the function performUpKeep to be too expensive to be called. On the other hand if any of the splitters's performUpKeep function reverts this will cause the whole function to revert, causing a DoS once again. For example if this condition is met - (uint256(newRewards) < controller.rewardThreshold()) the function will revert with InsufficientRewards().

https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/lstRewardsSplitter/LSTRewardsSplitterController.sol#L76

https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/lstRewardsSplitter/LSTRewardsSplitterController.sol#L93

Impact

  1. Reward distributions could be delayed or fail entirely, affecting user returns and trust in the protocol.

  2. The performUpKeep function can either hit the block gas limit or become too expensive to be called. This will make the function unusable.

Tools Used

Manual Review

Recommendations

  1. Modify the checkUpkeep and performUpkeep functions to process a limited number of splitters per transaction. Implement a mechanism to track which splitters have been processed and continue from that point in subsequent calls.

  2. Batch Processing: Implement a maximum batch size for processing splitters in a single transaction.

  3. Tracking: Implement a more gas-efficient way to track which splitters need upkeep, such as using a bitmap or a separate queue for splitters needing processing.

Updates

Lead Judging Commences

inallhonesty Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.