The PerpetualVault contract employs a _gmxLock state variable to lock the contract during GMX-related asynchronous operations. This prevents reentrant actions while awaiting GMX order execution callbacks. However, if an unexpected issue arises (e.g., a callback is never received or the GMX system fails), _gmxLock can become permanently stuck in the true state. This would effectively freeze all vault operations, preventing deposits, withdrawals, or position adjustments.
The _gmxLock is set to true during operations involving GMX and is only reset to false upon receiving a successful callback:
If the callback is never received or processing fails, _gmxLock remains true indefinitely.
Permanent Vault Freeze: Users would be unable to deposit, withdraw, or adjust positions.
Loss of Operational Control: Even privileged roles (e.g., owner, keeper) cannot override _gmxLock once set to true.
Multiple Reset Points: Although _gmxLock is set to false in multiple callback handlers, any missed or failed callback can still lead to a permanent lockup. Furthermore, setting _gmxLock = false in multiple places does not fully mitigate the risk, as any of these callbacks can revert, leaving _gmxLock stuck as true.
High Impact: Vault funds become inaccessible, and user operations halt indefinitely.
Likelihood: Moderate. While GMX failures or callback issues are rare, they are not impossible. External dependencies can always introduce unpredictable results so reverting callbacks are possible and prevention should be attempted.
Manual Code Review
Introduce an emergency unlock function to allow the owner to reset _gmxLock in case of failure:
This function should be used only in rare, emergency cases. Adding an event provides transparency when it is invoked.
An emergency mechanism prevents operational lockup without compromising normal contract security. As only the owner can invoke this function, the risk is minimal compared to the consequence of a frozen vault.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.