Overflow in Checkpoint Value Leading to Incorrect Balance Tracking and Reward Distribution
Summary
The StakingRewardsV2 contract uses uint128 to store checkpoint values for user balances and total supply. This design choice, likely made for gas optimization, introduces a potential overflow vulnerability when dealing with very large token amounts. If exploited, this could lead to incorrect balance tracking and consequently, erroneous reward distributions.
Vulnerability Detail
The vulnerability is present in the _addCheckpoint function, which is responsible for creating and updating checkpoints for user balances and total supply. The function casts a uint256 input value to uint128 when storing it in the checkpoint, potentially causing an overflow if the input value exceeds the maximum value that can be stored in uint128.
Impact
If exploited, this vulnerability could have severe consequences for the protocol and its users:
Incorrect Balance Tracking: Overflows would lead to incorrect balance recordings, potentially showing a much smaller balance than actually held.
Reward Calculation Errors: Since reward calculations depend on accurate balance tracking, this could lead to users receiving incorrect rewards. Some users might receive disproportionately large rewards, while others might receive far less than they're entitled to.
Unstaking Issues: Users might be unable to unstake their correct amount of tokens due to the recorded balance being incorrect.
While this vulnerability requires very large token amounts to exploit, it's important to note that we often see unexpectedly large amounts being used, especially in flash loan attacks or by whale accounts. Therefore, this vulnerability poses a real and significant risk to the protocol.
Use uint256 for Checkpoint Values:
Replace uint128 with uint256 for the 'value' field in the Checkpoint struct. This is the simplest solution and would prevent any overflow issues, albeit at the cost of increased gas usage.
struct Checkpoint {
uint64 ts;
uint64 blk;
uint256 value; // Changed from uint128 to uint256
}
Sparkly Grape Fly
Low/Info
Overflow in Checkpoint Value Leading to Incorrect Balance Tracking and Reward Distribution
Summary
The StakingRewardsV2 contract uses uint128 to store checkpoint values for user balances and total supply. This design choice, likely made for gas optimization, introduces a potential overflow vulnerability when dealing with very large token amounts. If exploited, this could lead to incorrect balance tracking and consequently, erroneous reward distributions.
Vulnerability Detail
The vulnerability is present in the
_addCheckpointfunction, which is responsible for creating and updating checkpoints for user balances and total supply. The function casts a uint256 input value to uint128 when storing it in the checkpoint, potentially causing an overflow if the input value exceeds the maximum value that can be stored in uint128.Impact
If exploited, this vulnerability could have severe consequences for the protocol and its users:
While this vulnerability requires very large token amounts to exploit, it's important to note that we often see unexpectedly large amounts being used, especially in flash loan attacks or by whale accounts. Therefore, this vulnerability poses a real and significant risk to the protocol.
Code Snippet
https://github.com/sherlock-audit/2024-07-kwenta-staking-contracts/blob/0527fb7425206a3338c23177416436c6286cedf9/token/contracts/StakingRewardsV2.sol#L618-L639
Tool used
Manual Review
Recommendation
Use uint256 for Checkpoint Values: Replace uint128 with uint256 for the 'value' field in the Checkpoint struct. This is the simplest solution and would prevent any overflow issues, albeit at the cost of increased gas usage.