A reentrancy vulnerability has been identified in the _runSwap
function of the PerpetualVault contract, where state changes occur after external calls.
Key issues:
External calls made before state updates
State variable swapProgressData
modified after external calls
Multiple external calls in sequence without state locks
Cross-function reentrancy possible through afterOrderCancellation
High severity:
Potential double-swaps
Incorrect state updates
Fund loss through repeated operations
Race conditions in swap execution
Slither static analyzer
Manual code review
Control flow analysis
Implement Checks-Effects-Interactions pattern
Add comprehensive reentrancy guards
Consider using OpenZeppelin's ReentrancyGuard
Add state validation checks
Implement emergency pause functionality
Add comprehensive event logging
Consider splitting complex operations
Add thorough testing for reentrancy scenarios
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.