Liquidity Management

Title

Issue with single OrderHandler whitelisting in gmxproxy contract

Summary

The GMXProxy contract currently only allows one OrderHandler to be whitelisted, but GMX's design supports multiple handlers running at the same time. This mismatch can cause problems when new handlers are added, as callbacks from the new handlers won't be accepted.

Vulnerability Details

GMX documentation reads:

"When creating a callback contract, the callback contract may need to whitelist the DepositHandler, OrderHandler, or WithdrawalHandler. It should be noted that new versions of these handlers may be deployed as new code is added to the handlers. It is also possible for two handlers to temporarily exist at the same time, e.g., OrderHandler(1), OrderHandler(2). Due to this, the callback contract should be able to whitelist and simultaneously accept callbacks from multiple DepositHandlers, OrderHandlers, and WithdrawalHandlers."

The validCallback modifier strictly checks against a single OrderHandler. If a new OrderHandler is deployed while the old one is still active, the contract will reject callbacks from the new handler until it's manually updated. This breaks the system when multiple handlers need to work together.

Impact

When multiple OrderHandlers are active, the system stops working. Callbacks from any handler not on the whitelist fail, which can halt order processing.

Tools Used

Manual Review

Recommendations

Update the validCallback modifier to support multiple OrderHandlers. This could involve using a list or set of allowed handlers. For example, you could store handlers in an array or mapping and check if the caller is in that list. Also, make sure updates to the whitelist are handled safely to avoid downtime.