# Limit orders are broken when there are price gaps

GMX limit/stop-loss orders revert when oracle prices gap past the trigger, leaving users unable to exit positions.

- Payout: Contest reward
- Severity: high
- Program: Gmx
- Credited: IllIllI
- Disclosed: 2022-09-22
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-02-gmx-judging/issues/140
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AH-7
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity vuln:business-logic

**Target:** GMX Synthetics order execution contracts
**Root cause:** Limit/stop-loss orders require primary and secondary oracle prices to straddle the trigger price; if a price gap moves both prices past the trigger, the straddle check fails and execution reverts.
**Steps:**
1. Submit a LimitDecrease or StopLossDecrease order with a trigger price.
2. Oracle primary/secondary prices gap so both are worse than trigger (both above for ascending, both below for descending).
3. Order execution calls BaseOrderUtils.setExactOrderPrice; check `primaryPrice <= triggerPrice && triggerPrice <= secondaryPrice` (or inverse) fails.
4. Execution reverts with InvalidOrderPrices, order never fills.
**How found:** Code review of the order price validation logic in BaseOrderUtils.setExactOrderPrice, noticing the strict straddle requirement combined with the requirement that oracle prices come from blocks after submission.
**Exploitation:** Not an attacker-driven exploit; a user's stop-loss/limit order fails to execute during a price gap, leaving the position exposed to further adverse price movement.
**Insight:** When auditing order/trigger validation, check what happens when prices jump past the trigger in a single block rather than crossing it gradually; strict straddle checks break on gaps.