Liquidity Management
Gamma
DeFiFoundry
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Event params from callbacks should be validated before its use

mrkaplan

Vulnerability details

When GMX handlers process an order, they make a callback to the GmxProxy.sol::afterOrderExecution() function, passing several parameters, one of which is EventLogData memory eventData:

struct EventLogData {
AddressItems addressItems;
UintItems uintItems;
IntItems intItems;
BoolItems boolItems;
Bytes32Items bytes32Items;
BytesItems bytesItems;
StringItems stringItems;
}

When the orderType is not of type MarketIncrease, this eventData is filled with important data (e.g., the value transferred to GmxProxy.sol when a liquidation or ADL occurs).
According to the integration notes of GMX:

Event data may be passed to callback contracts, the ordering of the params in the eventData will be attempted to be unchanged, so params can be accessed by index, for safety the key of the param should still be validated before use to check if it matches the expected value

The problem is that GmxProxy.sol::afterOrderExecution() uses this data, assuming it is in the correct order, and accesses the values without validating with the corresponding keys. If the data is incorrect, this could cause a severe disruption of the protocol and potentially lock funds in the GmxProxy contract (if the funds are not ETH).

Impact

  • Severe disruption of the protocol

  • Possible locked funds.

Root cause

Not checking the eventData params when afterOrderExecution() function is called

Tools used

Manual Review

Recommendations

Validate each value you are using inside the eventData with the corresponding keys.

Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Suppositions

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.

Support

FAQs

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

Give us feedback!