Closed c4-bot-7 closed 8 months ago
seems like minimal gas implications
141345 marked the issue as insufficient quality report
stake dust amt for other users, seems expected behavior, no loss
Invalid, the user's rewards are accrued in rewards[][]
thereksfour marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-03-abracadabra-money/blob/1f4693fdbf33e9ad28132643e2d6f7635834c6c6/src/staking/LockingMultiRewards.sol#L458-L477
Vulnerability details
Impact
In
LockingMultiRewards
contract: whenever a user stakes, withdraws or claims his rewards; his rewards are updated via_updateRewardsForUser()
function, where it loops over reward tokens and updates therewards[user_][token_]
via_udpateUserRewards()
function:As can be noticed, user's
rewards[user_][token_]
is updated based onrewardPerToken_ - userRewardPerTokenPaid * user's balance
, so that user's rewards balance can be updated only once per block as long as there's no update onrewardPerToken_
(vianotifyRewardAmount()
).This can be exploited by any malicious user to grief other users by staking dust unlocked amount (1 wei) on their behalf via
stakeFor()
function:and when the griefed user rewards are updated via
_updateRewardsForUser()
, theuserRewardPerTokenPaid[user]
will be set to the latestrewardPerToken_
, so when the griefed user calls any of the stake,withdraw or getRewards functions; the updated rewards will be less than he's entitled to becausependingUserRewardsPerToken = rewardPerToken_ - userRewardPerTokenPaid[user] = 0
(as long as therewardPerToken
hasn't been updated yet).Proof of Concept
LockingMultiRewards._stakeFor function
Tools Used
Manual Review.
Recommended Mitigation Steps
Add a minimum staking amount for
unlocked
stakes similar to theminLockAmount
used to check when creating locked stakes:Assessed type
Context