DeFiFoundry
50,000 USDC
View results
Submission Details
Severity: high
Invalid

After liquidation, gmx locks aren’t released causing the next keeper action to always revert

Target

contracts/PerpetualVault.sol

Vulnerability Details

After every call to the GMX proxy to execute an operation on GMX sets up a lock on the Vault contract which is only released during the execution of the callback when handing the response for GMX, this ensures that the keeper can only proceed with the next action only when the previous GMX operation has been executed and the vault contract is updated with the request response. However within the afterLiquidationExecution function, (which is the callback function responsible for handling liquidation action on GMX), the lock is not released as expected, this causes the next keeper operation to always revert thereby obstructing the flow sequence

function afterLiquidationExecution() external {
if (msg.sender != address(gmxProxy)) {
revert Error.InvalidCall();
}
depositPaused = true;
uint256 sizeInTokens = vaultReader.getPositionSizeInTokens(curPositionKey);
if (sizeInTokens == 0) {
delete curPositionKey;
}
if (flow == FLOW.NONE) {
flow = FLOW.LIQUIDATION;
nextAction.selector = NextActionSelector.FINALIZE;
} else if (flow == FLOW.DEPOSIT) {
flowData = sizeInTokens;
} else if (flow == FLOW.WITHDRAW) {
// restart the withdraw flow even though current step is FINALIZE.
nextAction.selector = NextActionSelector.WITHDRAW_ACTION;
}
}

PerpetualVault.afterLiquidationExecution

function runNextAction(MarketPrices memory prices, bytes[] memory metadata) external nonReentrant gmxLock {_onlyKeeper()

PerpetualVault.runNextAction

modifier gmxLock() {
if (_gmxLock == true) {
revert Error.GmxLock();
}
_;
}

PerpetualVault.gmxLock

Impact

Liquidation operations will always introduce a denial of service issue to the keeper causing important keeper actions to fail until the owner manually intervenes to reset the state of the vault.

Tools Used

Manual Review

Recommendations

Release the gmxlock by setting it to false after executing the afterLiquidationExecution callback.

Updates

Lead Judging Commences

n0kto Lead Judge 5 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding_gmxLock_not_reset_during_liquidation

Likelihood: Medium, every liquidation. Impact: Medium, runNextAction and cancelFlow are not usable before a `withdraw` or a `run`

Appeal created

sakshamseth5 Auditor
5 months ago
n0kto Lead Judge
5 months ago
n0kto Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.