You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 1, 2023. It is now read-only.
sherlock-admin opened this issue
Mar 27, 2023
· 0 comments
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
enlistInRollover() wrongly updates state of ownerToRollOverQueueIndex[_receiver]
Summary
When enlistInRollover() is called, either the user wants to newly enlist into the rollover, or that they want to update the amount in which they want their assets to rollover to the next epoch. The ownerToRollOverQueueIndex is updated wrongly when user wants to make an update to their rollover.
Vulnerability Detail
On L268, ownerToRollOverQueueIndex[_receiver] is updated to rolloverQueue.length even if user simply wants to update their rolloverQueue state. This is problemetic as it can lead to multiple different owners to the same rollover queue index and we illustrate how and why below.
function enlistInRollover(
uint256_epochId,
uint256_assets,
address_receiver
) publicepochIdExists(_epochId) minRequiredDeposit(_assets) {
// check if sender is approved by ownerif (
msg.sender!= _receiver &&isApprovedForAll(_receiver, msg.sender) ==false
) revertOwnerDidNotAuthorize(msg.sender, _receiver);
// check if user has enough balanceif (balanceOf(_receiver, _epochId) < _assets)
revertInsufficientBalance();
// check if user has already queued up a rolloverif (ownerToRollOverQueueIndex[_receiver] !=0) {
// if so, update the queueuint256 index =getRolloverIndex(_receiver);
rolloverQueue[index].assets = _assets;
rolloverQueue[index].epochId = _epochId;
} else {
// if not, add to queue
rolloverQueue.push(
QueueItem({
assets: _assets,
receiver: _receiver,
epochId: _epochId
})
);
}
ownerToRollOverQueueIndex[_receiver] = rolloverQueue.length; // L268emitRolloverQueued(_receiver, _assets, _epochId);
}
For eg, there are 5 users who have chosen to enlist in a rollover
The current ownerToRollOverQueueIndex of each user would be corresponding to the user number, i.e. user 1 is index 1.
Note that getRolloverIndex() subtracts this value by 1, so the actual index starts from 0.
Queue:
1 2 3 4 5
Now, the first user wants to update number of assets to rollover by and calls enlistInRollover().
After updating, ownerToRollOverQueueIndex[user1] = rolloverQueue.length = 5. The user's index is wrongly changed to 5.
At this point, both the rollover index of user1 and user5 is 5. This is extremely problematic in various cases.
For instance, the first user now calls delistRollOver(). User's index is now the last element, hence last element of queue is popped off. The mapping of user to index is removed.
However, this wrongly removes user5 from the rollover queue as well since they both share the same index. user5 will be unable to delist now and is forced to go through with the epoch.
Impact
Wrong implementation of enlistInRollover() will lead to varous problems. One example of the issue is shown, where a user is forced to go through with the epoch and do not have the option of delisting due to the inconsistency and mishandling of state.
ownerToRollOverQueueIndex[_receiver] should be updated only when a new user is added. This index state should not be updated when user is simply updating their rolloverQueue state.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
yixxas
high
enlistInRollover()
wrongly updates state ofownerToRollOverQueueIndex[_receiver]
Summary
When
enlistInRollover()
is called, either the user wants to newly enlist into the rollover, or that they want to update the amount in which they want their assets to rollover to the next epoch. TheownerToRollOverQueueIndex
is updated wrongly when user wants to make an update to their rollover.Vulnerability Detail
On L268,
ownerToRollOverQueueIndex[_receiver]
is updated torolloverQueue.length
even if user simply wants to update their rolloverQueue state. This is problemetic as it can lead to multiple different owners to the same rollover queue index and we illustrate how and why below.For eg, there are 5 users who have chosen to enlist in a rollover
The current
ownerToRollOverQueueIndex
of each user would be corresponding to the user number, i.e. user 1 is index 1.Note that
getRolloverIndex()
subtracts this value by 1, so the actual index starts from 0.Queue:
1 2 3 4 5
Now, the first user wants to update number of assets to rollover by and calls
enlistInRollover()
.After updating,
ownerToRollOverQueueIndex[user1] = rolloverQueue.length = 5
. The user's index is wrongly changed to 5.At this point, both the rollover index of user1 and user5 is 5. This is extremely problematic in various cases.
For instance, the first user now calls
delistRollOver()
. User's index is now the last element, hence last element of queue is popped off. The mapping of user to index is removed.However, this wrongly removes user5 from the rollover queue as well since they both share the same index. user5 will be unable to delist now and is forced to go through with the epoch.
Impact
Wrong implementation of
enlistInRollover()
will lead to varous problems. One example of the issue is shown, where a user is forced to go through with the epoch and do not have the option of delisting due to the inconsistency and mishandling of state.Code Snippet
https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L268
Tool used
Manual Review
Recommendation
ownerToRollOverQueueIndex[_receiver]
should be updated only when a new user is added. This index state should not be updated when user is simply updating their rolloverQueue state.Duplicate of #2
The text was updated successfully, but these errors were encountered: