Liquid Staking

Github

• https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/lstRewardsSplitter/LSTRewardsSplitter.sol#L104

Summary

The LSTRewardsSplitter contract contains a potential underflow vulnerability in the performUpkeep and splitRewards functions. Specifically, this vulnerability occurs when the contract attempts to adjust principalDeposits based on negative rewards, potentially resulting in an underflow. Additionally, the checkUpkeep function does not account for this scenario, which could lead to a Denial of Service (DoS) situation where performUpkeep cannot execute as intended.

Vulnerability Details

The underflow vulnerability is present in the following block of code:

Here, newRewards is calculated by subtracting the principalDeposits from the balance of liquid staking tokens (LST) in the contract. If the balance of LST is less than principalDeposits, newRewards becomes negative. The contract attempts to resolve this by converting the negative newRewards to a positive value (-1 * newRewards) and subtracting it from principalDeposits. This results in an underflow when principalDeposits is smaller than the absolute value of newRewards.

The checkUpkeep function currently allows the call to proceed even when underflow conditions might exist:

This function determines whether performUpkeep should be called. However, it doesn't properly handle the negative rewards scenario and allows performUpkeep to proceed, potentially triggering the underflow mentioned earlier. If the underflow occurs and the system goes into an invalid state, performUpkeep could fail, causing the system to be DoS-ed.

Example Scenario

• Step 1: The contract holds 50 LST tokens in principalDeposits.

• Step 2: The LST balance in the contract decreases due to external transfers, and now the LST balance is 10 tokens.

• Step 3: When newRewards is calculated as 10 - 50 = -40, the contract tries to subtract 40 from principalDeposits, leading to an underflow since principalDeposits only contains 50 tokens.

• Step 4: This results in an incorrect wraparound, pushing principalDeposits to a very large number, potentially breaking further calculations and functions relying on it.

Impact

The underflow scenario could lead to a state where principalDeposits becomes unsustainable for the contract's logic. As a result, subsequent calls to performUpkeep or splitRewards may revert, effectively preventing rewards distribution and rendering the contract inoperable in this regard causing DOS.

Tools Used

Manual Review

Recommendations

Add checks to ensure that principalDeposits is always greater than or equal to the absolute value of newRewards before subtracting. Also ensure that checkUpkeep considers the underflow condition and blocks any attempt to call performUpkeep when newRewards < 0.