Unimplemented frozen order handler in GmxProxy contract
The afterOrderFrozen function in the GmxProxy contract is empty, which means frozen orders aren't removed from the queue. This can cause the system to malfunction and potentially lead to denial-of-service attacks.
The afterOrderFrozen function is currently empty and doesn't handle frozen orders properly:
This means when an order is frozen on the GMX protocol, the order stays active in the queue without updating the requestKey or cleaning up the queue. The validCallback modifier only checks the caller and account but doesn't verify the order's status in the queue or if it was previously frozen.
This lack of validation can cause frozen orders to remain active, potentially disrupting the system.
Frozen orders stay active in the system
Manual Review
The afterOrderFrozen function should be updated to remove the frozen order from the queue if it matches the current order.
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.