Summary

emergencyPause does not cache the previous status; leading to permanent loss of requested but not processed deposit/withdraw.

The protocol make uses of status to clearly define what state the system is in, and what are the pre-requisite for executing a step-wise function to transition the system. For example, to handle the 2-step deposit/withdrawal inherent to GMX, upon deposit, the system would transition to self.status = GMXTypes.Status.Deposit;. And then a status of Deposit would be the requirement for the system to call execute processDeposit, through the afterDepositExecution callback from the GMX contract entry point executeDeposit

https://github.com/gmx-io/gmx-synthetics/blob/613c72003eafe21f8f80ea951efd14e366fe3a31/contracts/deposit/ExecuteDepositUtils.sol#L265

However, during when the system enters paused through emergencyPause. The system does not cache whatever the status is before transiting to Paused. And when the system resumes through emergencyResume and then processEmergencyResume, the status becomes Open` again.

So if the system was in Deposit or Withdraw, it cannot call processDeposit or processWithdraw, leading to a permanent tx stuck.

emergency:

Vulnerability Details

Impact

inconsistency in system status leading to a loss of deposit/withdraw prior to emergency pause.

Tools Used

Recommendations

consider a cache of system status and resume after emergency pause.