Liquidity Management

Details
The afterOrderCancellation function in the PerpetualVault contract resets the protocol’s next action (nextAction.selector) without sufficient state verification. Specifically, if the order cancellation is not flagged as a settlement (i.e. orderResultData.isSettle is false) and the order type is not a MarketSwap, the function unconditionally sets the next action based solely on the current flow (deposit or withdrawal). This reset occurs without verifying whether the underlying protocol state—such as pending orders, position data, or market conditions—remains valid for executing the intended next action. As a result, the protocol can transition to an unintended state that might trigger unsafe actions when runNextAction is later invoked.

Root Cause
The root cause is an overly simplistic state transition in afterOrderCancellation:

• Lack of Comprehensive State Checks: The function resets nextAction.selector based solely on the flow value without validating if all necessary conditions (e.g., current position health, market conditions, or pending order consistency) still hold.

• Assumed Correctness of Flow: The function assumes that the flow (deposit or withdraw) still accurately reflects the protocol’s intended operation even after an order cancellation, which may not be the case if conditions have changed or if the keeper has initiated the cancellation at an inopportune time.

Impact

• Unintended Execution of Actions: If the protocol’s state is not valid for an immediate increase or withdrawal, the forced reset of nextAction.selector may trigger market orders (e.g., an increase in position) under unfavorable conditions.

• Inconsistent Protocol State: Incorrect state transitions can lead to overleveraging, undercollateralization, or misallocation of funds, increasing the risk of losses or liquidation.

• Exploitation by Malicious Keepers: A malicious keeper (or one whose keys have been compromised) could intentionally cancel orders to manipulate the protocol’s state transitions and force execution of harmful actions.

Recommendation

• Implement Comprehensive State Validation: Before resetting the nextAction.selector in afterOrderCancellation, validate that the current protocol state (including pending order details, position metrics, and market conditions) is still appropriate for executing the intended next action.

• Introduce Guard Conditions: Add explicit guard clauses to ensure that the state transition is safe. For example:

  if (flow == FLOW.DEPOSIT && _canSafelyIncreasePosition()) {

  nextAction.selector = NextActionSelector.INCREASE_ACTION;

  nextAction.data = abi.encode(beenLong);

  } else if (flow == FLOW.WITHDRAW && _canSafelyWithdraw()) {

  nextAction.selector = NextActionSelector.WITHDRAW_ACTION;

  } else {

  // Revert or transition to a safe default state

  revert("Unsafe state transition after order cancellation");

  }

  Here, _canSafelyIncreasePosition() and _canSafelyWithdraw() would perform detailed checks on the protocol state.

• Restrict and Monitor Keeper Privileges: Ensure that the keeper role is tightly controlled and monitored. Consider multi-signature or additional delay mechanisms for state-changing operations initiated by keepers.

• Enhanced Logging: Add detailed events and logging around state transitions triggered by order cancellations so that abnormal state changes can be detected and audited in real time.

Proof of Concept (PoC)

1. Setup:

   • The protocol is in a deposit flow (FLOW.DEPOSIT) with a pending order to increase the position.

   • The keeper-controlled nextAction.selector is expected to drive the position increase upon order execution.

2. Attack Scenario:

   • A malicious keeper (or an attacker who has compromised the keeper account) intentionally calls cancelOrder(), which eventually triggers afterOrderCancellation.

   • Since the order is neither marked as a settlement nor a MarketSwap, the function sets nextAction.selector to INCREASE_ACTION without verifying if conditions are still favorable.

3. Exploitation:

   • The attacker then calls runNextAction(), causing the contract to execute _createIncreasePosition based on potentially outdated parameters.

   • If market conditions have changed or if the underlying position is no longer valid for an increase, this forced action may lead to overleveraging, mispricing, or even loss of funds.

4. Outcome:

   • The protocol executes an increase action under unsafe conditions, potentially leading to undercollateralization or other unintended financial exposures, adversely impacting depositors and overall protocol health.

This report identifies the vulnerability and provides actionable recommendations to mitigate the risk of unsafe state transitions resulting from an unguarded reset in the afterOrderCancellation function.