Liquidity Management

GMXProxy

Summary

Design flaw exists in its management of the global order queue. Specifically, the contract uses a single OrderQueue struct to store both the order’s unique request key and an isSettle flag that indicates whether the order is a settlement order. Because new orders simply overwrite this global queue without verifying that a previous order has been fully processed, concurrent or rapidly submitted orders can cause the isSettle flag to be overwritten. This leads to a situation where the callback for an earlier order may be processed with the wrong flag, causing the PerpetualVault to misinterpret the order type and update its state incorrectly.

Where the Issue Is

• Order Creation in GMXProxy:
  When a regular order is created via createOrder, the global queue is set with:

  queue.requestKey = keyA; // for Order A

  // Implicitly, queue.isSettle remains false (default)

  ​

  Later, when a settlement order is created via settle, the same global queue is overwritten:

  queue.requestKey = keyB; // for Order B

  queue.isSettle = true;

  ​

  No check is made to ensure that an active order (Order A) has been completed before overwriting the global queue.

• Callback Handling:
  In afterOrderExecution (and similarly in afterOrderCancellation), the contract reads the current value of queue.isSettle and includes it in the order result data sent to PerpetualVault. If Order A’s callback is executed after Order B has been submitted, the callback for Order A will erroneously use isSettle = true (from Order B), misrepresenting Order A as a settlement order.

Root Cause

The root cause of the vulnerability is that the GMXProxy contract relies on a single, global OrderQueue struct for all order submissions without binding the isSettle flag to a unique order identifier. In effect, if multiple orders are initiated in close succession—either accidentally or through attacker‐induced race conditions—the global state is overwritten. There is no on‑chain mechanism (e.g., a mapping from request keys to order metadata) to ensure that callbacks are processed against the vault state snapshot corresponding to the order’s creation.

Clear Attack Path / Scenario

1. Order A (Regular Order) Submission:

   • PerpetualVault calls createOrder, setting:
     queue.requestKey = keyA
queue.isSettle = false

   • Order A is recorded as a regular (non-settlement) order.

2. Order B (Settlement Order) Submission:

   • Before Order A’s callback is processed, PerpetualVault calls settle, which overwrites the global queue with:
     queue.requestKey = keyB
queue.isSettle = true

3. Callback for Order A:

   • GMX later triggers the callback for Order A.

   • The callback function in GMXProxy uses the current global queue, finding requestKey = keyB and isSettle = true.

   • As a result, the PerpetualVault receives data indicating that Order A was a settlement order, leading to incorrect state updates (for example, marking a position as settled when it is not) or misallocation of fees.

Impact

• State Inconsistency: The PerpetualVault may misinterpret the type of order it is processing. This can result in incorrect collateral adjustments, fee misallocation, or errors in share minting.

• Financial Loss: Persistent misinterpretation of order types could allow an attacker—or even result from a coding error—to “game” the vault state, leading to extraction or diversion of funds.

• Invariant Violation: The protocol’s core invariants regarding fair and consistent fee accounting and state management are violated.

Recommendation

To mitigate this vulnerability, the order tracking should be redesigned so that each order’s isSettle flag is stored independently:

• Mapping Approach:
  Replace the single global queue with a mapping keyed by the unique order request key:

  mapping(bytes32 => bool) public orderIsSettle;

  bytes32 public latestRequestKey; // (Optional: if tracking the latest order is needed)

  ​

  Then, in createOrder and settle, store:

  // In createOrder:

  orderIsSettle[requestKey] = false;

  latestRequestKey = requestKey; // Optional

  ​

  // In settle:

  orderIsSettle[requestKey] = true;

  latestRequestKey = requestKey; // Optional

  ​

  Finally, in callback functions (e.g., afterOrderExecution), retrieve the order’s flag using the unique request key:

  bool isSettleForOrder = orderIsSettle[requestKey];

  delete orderIsSettle[requestKey]; // Clean up after callback

  ​

• Alternative Approach:
  Enforce single-order processing by checking that no order is currently active before allowing a new one. However, this may restrict concurrent order handling, so the mapping approach is preferable.

Severity

High – This vulnerability directly impacts the integrity of order processing, which may lead to misallocation of funds or incorrect state transitions in the protocol.

Proof-of-Concept (Foundry PoC)

Below is a Foundry PoC that simulates the vulnerability by using simplified versions of the GMXProxy and PerpetualVault components. The PoC demonstrates that when a regular order is submitted (with isSettle = false) and then a settlement order is submitted (with isSettle = true), the global queue is overwritten. Consequently, a callback for the first order incorrectly interprets the order type.

File: src/FakeGmxProxy.sol

File: src/FakeVault.sol

File: test/FakeVaultTest.t.sol

From the project root, run:

The test should pass—demonstrating that when Order B (settlement order) is submitted before Order A’s callback, the global queue’s isSettle flag is overwritten. As a result, the callback for Order A misinterprets the order as a settlement order.