Closed sherlock-admin closed 1 year ago
Escalate for 10 USDC
First, please ignore this issue title because I think it's not clearly describe the issue (and too short), so read from the Summary, Vulnerability Detail, and the Impact of this issue.
This is exactly the same as #355 (which is a duplicate of #418), and it is about rollover will failed/grieving/bricked.
The rollover mechanism would forever be bricked for entries after the bad entry (the automatic generated entry where assets <= relayerFee).
is same as this issuethe problematic code
uint256 assetsToMint = queue[index].assets - relayerFee;
is also the same in
355
418
You've deleted an escalation for this issue.
Escalate for 10 USDC
The previous escalation is wrong...
This is exactly the same as #355 (which is a duplicate of #418), and it is about rollover will failed/grieving/bricked.
The issues the escalator links to point out a different issue.
This current issue is invalid because this check will skip over any entries where
queue[index].assets - relayerFee
will underflow.What I described in the "bonus" section of my issue, and what Bernd described in his issue, is that there's a special edge case where the vault's TVL is 0 and there will be a division by 0 error. That division happens before the abovementioned check. So that is a similar, but different, issue than the one that is pointed out here (and which is invalid as is taken care of by the abovementioned check).
You've deleted an escalation for this issue.
Escalate for 10 USDC
The previous escalation is wrong...
This is exactly the same as #355 (which is a duplicate of #418), and it is about rollover will failed/grieving/bricked.
The issues the escalator links to point out a different issue.
This current issue is invalid because this check will skip over any entries where
queue[index].assets - relayerFee
will underflow.What I described in the "bonus" section of my issue, and what Bernd described in his issue, is that there's a special edge case where the vault's TVL is 0 and there will be a division by 0 error. That division happens before the abovementioned check. So that is a similar, but different, issue than the one that is pointed out here (and which is invalid as is taken care of by the abovementioned check).
After reading it again I think you're right Kenzo, thanks for the correction, I missed that point, thus removed my escalation. Congrats for the result.
Congrats for the result.
Thank you mate 🙂
chainNue
medium
Rollover doesn't check next epoch
minRequiredDeposit
(relayerFee)Summary
rollover doesn't check next epoch
minRequiredDeposit
in scenario where the next epoch'srelayerFee
is increasing, resulting a failed mint of the rolloverVulnerability Detail
When user want to enlist rollover, they will call
enlistInRollover()
which have modifierminRequiredDeposit
of asset they are trying to rollover. but thenmintRollovers
doesn't check again thisrelayerFee
(because it might be increased).if for example a user deposit a minimum amount of deposit, so to speak, they just deposit right amount just to pass
minRequiredDeposit
, then when the next epoch's relayerFee is greater than previous relayerFee, themintRollovers()
will failed.since the asset is previously equal to relayerFee (on previous epoch), and if next epoch the relayerFee is increasing, this will failed / reverted without any handling.
Impact
User will failed to rollover their position because next epoch's
relayerFee
might be larger than previous epoch'srelayerFee
.Code Snippet
https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L436
Tool used
Manual Review
Recommendation
When calling
enlistInRollover
need to have a check on if the asset amount will pass theminRequiredDeposit
(or not less than next epoch's relayerFee). because if not it will successfully enlisted in rollover, but later when trying to mint, it will failed.