Skip to content
This repository has been archived by the owner on Oct 1, 2023. It is now read-only.

ck - mintRollovers should remove rollovers after successful execution #380

Closed
sherlock-admin opened this issue Mar 27, 2023 · 4 comments
Closed
Labels
Escalation Resolved This issue's escalations have been approved/rejected Excluded Excluded by the judge without consulting the protocol or the senior Non-Reward This issue will not receive a payout

Comments

@sherlock-admin
Copy link
Contributor

ck

medium

mintRollovers should remove rollovers after successful execution

Summary

mintRollovers should remove rollovers after successful execution

Vulnerability Detail

After a successful rollover, the mintRollovers just replaces the assets and epochId of a user with new values.

                    rolloverQueue[index].assets = assetsToMint;
                    rolloverQueue[index].epochId = _epochId;
                    // only pay relayer for successful mints
                    executions++;

The issue is that after a successful rollover that a user had enrolled for has succeeded, they remain in the queue with new values and their old index.

Let's say they want to enroll some more assets. Since they still exist in the rolloverQueue, their index in the queue will remain the same:

        // check if user has already queued up a rollover
        if (ownerToRollOverQueueIndex[_receiver] != 0) {
            // if so, update the queue
            uint256 index = getRolloverIndex(_receiver);
            rolloverQueue[index].assets = _assets;
            rolloverQueue[index].epochId = _epochId;

Now going back to the mintRollovers function, their index has already been recorded as successful:

if (executions > 0) rolloverAccounting[_epochId] = index;

This means, that when the starting index of the mintRollovers function will be a value higher than the user's position in the queue and no rollover will happen for their additional assets.

uint256 index = rolloverAccounting[_epochId];

Impact

Users who enlist for rollover of additional assets will not have it executed.

Code Snippet

https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L361-L459

https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L253-L257

Tool used

Manual Review

Recommendation

Remove a user from the rolloverQueue after a successful rollover so that when they enlist again, they are pushed to the end of the queue.

@github-actions github-actions bot closed this as completed Apr 3, 2023
@github-actions github-actions bot added the Excluded Excluded by the judge without consulting the protocol or the senior label Apr 3, 2023
@sherlock-admin sherlock-admin added the Non-Reward This issue will not receive a payout label Apr 11, 2023
@iamckn
Copy link

iamckn commented Apr 13, 2023

Escalate for 10 USDC

This should not have been excluded as it breaks rolling functionality and prevents users from rolling over additional assets.

@sherlock-admin
Copy link
Contributor Author

Escalate for 10 USDC

This should not have been excluded as it breaks rolling functionality and prevents users from rolling over additional assets.

You've created a valid escalation for 10 USDC!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

@hrishibhat
Copy link

Escalation rejected

Valid informational
A user cannot enter the same epoch mint queue twice is a design limitation, not a valid high/medium

@sherlock-admin
Copy link
Contributor Author

Escalation rejected

Valid informational
A user cannot enter the same epoch mint queue twice is a design limitation, not a valid high/medium

This issue's escalations have been rejected!

Watsons who escalated this issue will have their escalation amount deducted from their next payout.

@sherlock-admin sherlock-admin added Escalation Resolved This issue's escalations have been approved/rejected and removed Escalated This issue contains a pending escalation labels Apr 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Escalation Resolved This issue's escalations have been approved/rejected Excluded Excluded by the judge without consulting the protocol or the senior Non-Reward This issue will not receive a payout
Projects
None yet
Development

No branches or pull requests

3 participants