Closed code423n4 closed 1 year ago
dmvt marked the issue as duplicate of #156
RedVeil marked the issue as disagree with severity
RedVeil marked the issue as sponsor confirmed
dmvt changed the severity to QA (Quality Assurance)
Revert back to M as requested by @dmvt
dmvt marked the issue as satisfactory
dmvt marked the issue as partial-50
Lines of code
https://github.com/code-423n4/2023-01-popcorn/blob/d95fc31449c260901811196d617366d6352258cd/src/utils/MultiRewardStaking.sol#L308 https://github.com/code-423n4/2023-01-popcorn/blob/d95fc31449c260901811196d617366d6352258cd/src/utils/MultiRewardStaking.sol#L357
Vulnerability details
Impact
The
changeRewardSpeed()
function computesrewardsEndTimestamp
incorrectly for the caseblock.timestamp < prevEndTime
. For example, it may increase therewardsEndTimestamp
by several years forward despite the fact that the fund will be enough for one day only. As a result, some users will claim extra rewards at the expense of other users.Proof of Concept
The function
changeRewardSpeed()
calculatesrewardsEndTimestamp
viaIf the
prevEndTime > block.timestamp
then it can be reduced to_calcRewardsEnd(prevEndTime, rewardsPerSecond, remainder)
where theremainder
is the contract's reward token balance.Then, in the
_calcRewardsEnd()
the first condition is met and theamount
value is increased fromremainder
toremainder + rewardsPerSecond * (timeLeft)
:Thus, the
amount
becomes larger the original contract's reward token balance and the newrewardsEndTimestamp
is calculated incorrectly:You can use the following forge test to check for the error. Put the following test in
./test/
folder and run withforge test --mc IncorrectComputation
. The test fails becauserewardsEndTimestamp
calculations are wrong:Tools Used
Manual analysis
Recommended Mitigation Steps
Fix
rewardsEndTimestamp
calculations