warRoom - Inablility to withdraw for users enlisted in depositQueue()

[sherlock-admin]

warRoom

high

Inablility to withdraw for users enlisted in depositQueue()

Summary

Carousel users who are enlisted in depositQueue have no way to withdraw funds if their deposits are not processed.

Vulnerability Detail

Where: In Carousel.sol- function _deposit()

When: When carousel users deposit with Epoch 0.

Description :

Consider a scenario :

• There is a user who wants to deposit in nextEpoch, so he calls deposit with Epoch 0.
• In _deposit() functions, no shares are minted to this user for the underlying provided; only her entry is added in depoistQueue Array.
• Now consider that her deposit is not processed due to some reason such as below
  • No one calls mintDepositInQueue()
  • Relayer does call mintDepositInQueue() but for limited operations
• There is no way for user to call withdraw, as she hasn't been minted any shares.
• Here, we believe functionality to withdraw is unnecessarily dependent on relayers calling mintDepositInQueue()

Impact

• Permanent freezing of funds for users.

Code Snippet

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

Tool used

Manual Review

Recommendation

• Consider minting shares of Id 0 for users who call _deposit() function with epoch Id 0, so that when withdraw is called, the user's shares are burned and underlying is returned.

[nemveer]

Escalate for 10 USDC

We think this is wrongly classified as a duplicate of #68.

In #68, Watson implies that once a deposit has been made, the depositor won't be able to cancel it.

Whereas we here want to point out a situation where if the deposit of the user is not processed due to any reason(DOS, relayer calls mintDepositInQueue() with limited operations etc.), the depositor won't be able to withdraw his funds.

There is a possibility that the deposit will be processed in any upcoming epoch if not the next one, but User may not want to deposit in that Epoch but he has no choice.

[sherlock-admin]

Escalate for 10 USDC

We think this is wrongly classified as a duplicate of #68.

In #68, Watson implies that once a deposit has been made, the depositor won't be able to cancel it.

Whereas we here want to point out a situation where if the deposit of the user is not processed due to any reason(DOS, relayer calls mintDepositInQueue() with limited operations etc.), the depositor won't be able to withdraw his funds.

There is a possibility that the deposit will be processed in any upcoming epoch if not the next one, but User may not want to deposit in that Epoch but he has no choice.

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]

Escalation accepted

Not a duplicate of #68
Although not exactly a duplicate of #68 the comment on that issue partially applies here too. Wrt this issue mintDepositInQueue can be called by anyone and not being able to withdraw at will can be subject to last-minute manipulation so this seems like a design choice.
There is not valid high/medium issue here.

[sherlock-admin]

Escalation accepted

Not a duplicate of #68
Although not exactly a duplicate of #68 the comment on that issue partially applies here too. Wrt this issue mintDepositInQueue can be called by anyone and not being able to withdraw at will can be subject to last-minute manipulation so this seems like a design choice.
There is not valid high/medium issue here.

This issue's escalations have been accepted!

Contestants' payouts and scores will be updated according to the changes made on this issue.