Liquid Staking

Summary

A vulnerability has been identified in the StakingPool contract where the FundFlowController assumes a fixed number of strategies (two) when constructing deposit data. This assumption can lead to deposit failures when more than two strategies are added to the StakingPool and a deposit amount exceeds the capacity of the first two strategies.

Vulnerability Details

In StakingPool.sol:287, the addStrategy function allows the owner to add new strategies to the StakingPool. However, the FundFlowController's (getDepositData(uint256))[https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/linkStaking/FundFlowController.sol#L75] function always returns an array of two slots, regardless of the actual number of strategies in the pool.

This mismatch creates a problem when:

1. More than two strategies are added to the StakingPool.

2. A user attempts to make a deposit that doesn't fit entirely in the first two strategies.

3. The StakingPool determines that some or all of the remaining amount can be deposited in the third (or subsequent) strategy.

In this scenario, the StakingPool will attempt to access strategy data from the _data array passed to the deposit function, but this array only contains data for the first two strategies. This results in an out-of-bounds exception and the deposit transaction will revert.

Impact

The impact of this vulnerability is significant:

1. Deposit failures: Users may be unable to complete deposits if the amount exceeds the capacity of the first two strategies, even if there is available capacity in other strategies.

2. Reduced functionality: The functionality of FundFlowController as a mean to easily deposit to strategies become useless.

3. Poor user experience: Users may face unexpected transaction failures.

Tools Used

Manual Review

Recommendations

To address this vulnerability, consider the following recommendations:

1. Modify the FundFlowController's getDepositData function to dynamically generate data for all available strategies, not just the first two.

2. Implement proper bounds checking when accessing strategy data in the deposit function to gracefully handle cases where data for a strategy might be missing.

3. Consider implementing a more flexible design that doesn't rely on a fixed array size for strategy data, allowing for easier scalability as new strategies are added.