Liquid Staking

Github

• https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/priorityPool/PriorityPool.sol#L377

Summary

There is a potential underflow issue in the claimLSDTokens function in the PriorityPool contract. This vulnerability occurs during the subtraction of claimed amounts from the total tokens or shares a user is entitled to claim. If the already claimed amount is greater than the total amount being requested, an underflow can occur, potentially causing a Denial of Service (DoS). While Solidity 0.8.x automatically reverts transactions on underflow, it is important to address this explicitly in the contract to ensure robust error handling.

Vulnerability Details

There are two underflow areas in the function :

• amountToClaim = _amount - accountClaimed[account]: The calculation here subtracts the amount the user has already claimed from the total amount they are now trying to claim.

• sharesAmountToClaim = _sharesAmount - accountSharesClaimed[account]: Similarly, this calculation subtracts the staking shares already claimed from the total shares they are attempting to claim now.

These underflows can occur if the user has already claimed more tokens or shares than they are now trying to claim. In such cases, the subtraction will result in a negative value, which in older versions of Solidity (pre-0.8.x) would have caused an underflow (wrapping around to a large positive number).

Example Scenario

Step 1: Initial Claim (High Amount Claimed)

• First Transaction: A user successfully claims 200 tokens from the staking pool.

• The contract records this by setting accountClaimed[account] = 200.

• This is stored as part of the user's claim history so that the system can keep track of how much has already been claimed.

Step 2: Second Claim (Attempt to Claim Lower Tokens)

• Second Transaction: The user later comes back and tries to claim 150 tokens, mistakenly thinking they have that amount remaining.

• In this case, the function attempts to calculate how many tokens are still available for the user to claim:

• Since the user has already claimed 200 tokens, but is now trying to claim only 150, this results in a negative number (-50 tokens). In Solidity (prior to version 0.8.x), this would have caused an underflow, wrapping around and creating a large positive number.

Step 3: Reverting Transaction Due to Underflow

In Solidity 0.8.x, underflows no longer result in wrapping around to large numbers. Instead, they trigger an automatic revert, meaning the entire transaction fails and no tokens are claimed. This prevents incorrect calculations, but the problem is that it creates a Denial of Service (DoS) scenario. When the transaction reverts, the user cannot proceed with their claim, and other users might also be affected if this issue is not handled.

A user might repeatedly trigger this underflow either by accident (because they mistakenly think they have more tokens to claim) or maliciously (to prevent other users from making successful claims). Since the transaction reverts, the function is effectively locked until the offending transaction is resolved, which can impact the entire system.

Impact

If a user submits a claim request with a lower _amount or _sharesAmount than they have already claimed, the function reverts due to an underflow. This prevents the user from completing the claim and may block other users from making valid claims, creating a DoS condition.

Users might be unable to claim their staking rewards or liquid tokens due to an ongoing DoS attack or repeated claim failures by a single user.

Tools Used

Manual Review

Recommendations

Either allow less amount to be claimed from previous claimed amount or do proper underflow managment.