Liquidity Management

Brief

The PerpetualVault contract’s deposit flow management code can enter a permanently locked state if a GMX position operation stalls or never issues its callback. When a user deposits funds while a position is open, the vault sets its internal flow state to FLOW.DEPOSIT and waits for GMX to complete an “increase position” call. If GMX fails to respond, the contract remains stuck in FLOW.DEPOSIT with its lock set, preventing any further deposits, withdrawals, or flow cancellations. Only an unsafe manual intervention by the contract owner can reset this state, leaving user funds trapped indefinitely.

Details

The vulnerability comes from the interplay between the contract’s rigid flow states, the GMX callback mechanism, and the locking modifier that forbids state cancellation while waiting on GMX. A closer look at the relevant sections:

1. In the deposit function, the vault transitions into FLOW.DEPOSIT:

   function deposit(uint256 amount) external nonReentrant payable {

   _noneFlow();

   // ...

   flow = FLOW.DEPOSIT;

   collateralToken.safeTransferFrom(msg.sender, address(this), amount);

   // ...

   if (!positionIsClosed) {

   _payExecutionFee(counter, true);

   nextAction.selector = NextActionSelector.INCREASE_ACTION;

   nextAction.data = abi.encode(beenLong);

   }

   }

   • The code sets flow = FLOW.DEPOSIT, blocking other user actions until the deposit flow finishes.

   • If a GMX position is already open (positionIsClosed == false), the vault prepares to “increase” that position instead of simply minting shares.

2. The vault then calls GMX to open or increase a position and sets _gmxLock = true:

   function _createIncreasePosition(...) internal {

   // ...

   _gmxLock = true;

   gmxProxy.createOrder(orderType, orderData);

   }

   ​

   While _gmxLock remains true, the vault forces any future deposit/withdraw to revert. A callback from GMX is expected to clear this lock.

   ​

3. If GMX never completes or cancels the order, the vault remains stuck:

   • The cancelFlow() function is guarded by a modifier that reverts if _gmxLock == true.

   • Normal user actions are disallowed because _noneFlow() checks flow == FLOW.NONE.

   • The only built-in fallback (setVaultState) is an extremely privileged owner function with minimal checks, risking more inconsistent states.

This rigid design creates a path for indefinite blocking: once in FLOW.DEPOSIT with _gmxLock == true, no state transitions can occur without a successful GMX callback or direct owner override. Hence, user funds become stuck in the contract, and standard operations cannot proceed.

Specific Impact

The vulnerability can effectively freeze the entire vault, permanently blocking deposits and withdrawals if GMX fails to respond for any reason, resulting in a denial of service and trapping user collateral without a safe, automated recovery path.

Proof Of Concept

Run with forge test --match-test test_Y1_PermanentLock_DueToMissingGmxCallbacks

LOGS: