The afterOrderExecution
function in the GmxProxy
contract handles the callback from the GMX order execution controller. This function processes the executed order, claims funding fees, and transfers tokens to the perpetual vault. However, there are potential high-severity issues related to unchecked external calls and reentrancy vulnerabilities.
Unchecked External Calls: The function makes external calls to transfer tokens to the perpetual vault without checking for success. This could lead to unexpected failures if the token transfer fails.
Reentrancy Vulnerability: The function transfers tokens to the perpetual vault without using a reentrancy guard. This could potentially be exploited if the perpetual vault contract has a fallback function that calls back into the GmxProxy contract.
Unchecked External Calls: If the token transfer fails, the function may not behave as expected, leading to potential loss of funds or incorrect state updates.
Reentrancy Vulnerability: An attacker could exploit the reentrancy vulnerability to repeatedly call the function and drain funds from the contract or manipulate its state.
manual review
Add Reentrancy Guard: Use a reentrancy guard modifier to protect the function from reentrancy attacks.
Check External Calls for Success: Ensure that all external calls, especially token transfers, are checked for success.
Emit Events for Critical Actions: Emit appropriate events for critical actions such as order execution and token transfers to facilitate tracking and auditing.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.