DeFiFoundry
20,000 USDC
View results
Submission Details
Severity: low
Invalid

Potential Arithmetic Underflow in unstake Function Due to Insufficient Input Validation

Summary

A medium severity vulnerability has been identified in the unstake function of the FjordStaking contract. The current implementation lacks proper input validation for the _epoch parameter, which could lead to an arithmetic underflow when calculating the difference between the current epoch and the input epoch. This could result in unexpected behavior, including bypassing the intended lock period for unstaking.

Vulnerability Details

The vulnerability is present in the unstake function:

function unstake(uint16 _epoch, uint256 _amount)
external
checkEpochRollover
redeemPendingRewards
returns (uint256 total)
{
// ... (previous code omitted for brevity)
if (currentEpoch != _epoch) {
if (currentEpoch - _epoch <= lockCycle) revert UnstakeEarly();
}
// ... (rest of the function)
}

The issue lies in the calculation currentEpoch - _epoch. If _epoch is greater than currentEpoch, this subtraction will result in an arithmetic underflow, as these variables are of type uint16. In Solidity 0.8.x, which this contract uses, arithmetic underflows cause the transaction to revert.

Impact

The impact of this vulnerability includes:

  1. Unexpected Reverts: Transactions may revert due to arithmetic underflow rather than the intended UnstakeEarly error, leading to confusion for users and developers.

Tools Used

Manual

Recommendations

To address this vulnerability and improve the robustness of the unstake function, we recommend adding an explicit check to ensure that the input _epoch is not greater than the currentEpoch. Here's the suggested fix:

function unstake(uint16 _epoch, uint256 _amount)
external
checkEpochRollover
redeemPendingRewards
returns (uint256 total)
{
// ... (previous code remains the same)
if (_epoch > currentEpoch) revert InvalidEpoch();
if (currentEpoch != _epoch) {
if (currentEpoch - _epoch <= lockCycle) revert UnstakeEarly();
}
// ... (rest of the function remains the same)
}

This modification ensures that:

  1. The function reverts with a clear error message if a future epoch is provided.

  2. It prevents any potential arithmetic underflow in the subsequent calculations.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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