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

Unused Key Parameter in Modifier

Summary

The GmxProxy::validCallback modifier does not validate the bytes32 key parameter, making its inclusion redundant and potentially leading to unexpected behavior.

Vulnerability Details

modifier validCallback(bytes32 key, Order.Props memory order) {
require(
msg.sender == address(orderHandler) ||
msg.sender == address(liquidationHandler) ||
msg.sender == address(adlHandler),
"invalid caller"
);
require(order.addresses.account == address(this), "not mine");
_;
}

The validCallback modifier takes a bytes32 key parameter but does not use it within its logic. This indicate an oversight where validation or processing of the key was intended but not implemented. If the key is meant to be validated, failing to do so could introduce logical errors or security risks.

Impact

  • If the key is meant to be validated, its absence in the logic could allow unintended access or incorrect processing.

  • If the key is not needed, its presence in the modifier creates confusion and unnecessary complexity.

  • If the events like GmxPositionCallbackCalled PerpetualVault::afterOrderExecution() , PerpetualVault::afterOrderCancellation()' or afterOrderFrozen` meant to be pick by offchain scripts that would cause trouble

Tools Used

Manual Code Review

Recommendations

Either remove the key parameter from the modifier if it is unnecessary or implement a validation check such as:

modifier validCallback(bytes32 key, Order.Props memory order) {
+ require(key.length > 0, "invalid key");
require(
msg.sender == address(orderHandler) ||
msg.sender == address(liquidationHandler) ||
msg.sender == address(adlHandler),
"invalid caller"
);
require(order.addresses.account == address(this), "not mine");
_;
}
Updates

Lead Judging Commences

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

Informational or Gas

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.

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!