Liquidity Management

GmxProxy.sol

Observation:
While many parts of the protocol use nonReentrant modifiers, GmxProxy’s critical functions such as createOrder and settle do not explicitly apply reentrancy guards. They interact with external contracts (e.g. gExchangeRouter) and update state (e.g. writing to the global queue) without protection against reentrant calls.

Validated Issue:
Even though these functions are restricted (e.g. only callable by the trusted PerpetualVault), any unforeseen behavior from an external contract or a misconfiguration in the vault might allow an attacker to trigger reentrant calls. For instance, if gExchangeRouter or one of its callbacks were to call back into GmxProxy (directly or indirectly), it could potentially overwrite the queue or manipulate execution fee transfers—undermining the protocol’s expected state transitions and financial calculations.

Recommendation:
Apply a nonReentrant modifier (or equivalent reentrancy protection) on functions that perform external calls and update global state, such as createOrder and settle. This extra layer of defense will help ensure that even if an external call behaves unexpectedly, the internal state remains consistent.