Completing unqueued withdrawal loses and locks funds
Description
In the queued withdrawal-deposit process, a user first initiates a queued withdrawal with EigenLayer where the withdrawer is set as the Liquifier contract, and then they call depositWithQueuedWithdrawal on Liquifier to get minted a corresponding amount of eETH. This sets an entry of the mapping isRegisteredQueuedWithdrawals to true in order to prevent the user from reusing the same withdrawal.
Later, after the withdrawal can be finalized, an admin calls completeQueuedWithdrawals to complete the withdrawal and receive the funds. However, this function does not check the isRegisteredQueuedWithdrawals, so an admin could maliciously, accidentally, or be tricked into completing a withdrawal that has not yet been used to mint eETH.
Impact
If an admin completes a queued withdrawal that was not deposited, the depositor can still use it to mint eETH. This means that the amount of eETH minted can correspond to the value of the shares at a future time instead of at or before the Liquifier cashes in, which means the Liquifier loses money to the depositor.
Additionally, while the depositor has not deposited the withdrawal, a corresponding amount of funds are locked in the Liquifier. This is because the withdrawal process will decrease tokenInfos[token].strategyShare even though no deposit increased it by the amount of shares. So, if the admin tries to complete other legitimate withdrawals, during the last ones, the decreasing of this statistic will underflow and cause the completion to revert.
Recommendations
Check isRegisteredQueuedWithdrawals in completeQueuedWithdrawals and skip the withdrawal if it has not been deposited.
Alternatively, in order to better help users who mistakenly initiate a withdrawal but then do not call depositWithQueuedWithdrawal — if called on a withdrawal that has not been deposited, the completion function could mint them an amount of eETH that they would have gotten if they deposited immediately prior to the completion.
Remediation
This issue has been acknowledged by Gadze Finance SEZC, and fixes were implemented in the following commits: