Steadefi
Steadefi
DeFiHardhatFoundryOracle
35,000 USDC
View results
Previous Next
Submission Details
Severity: medium
Valid

REENTRANCY_IN_PROCESS_WITHDRAW

asimaranov

Summary

Contract reentrant call while state is inconsistent possibility

Vulnerability Details

In GMXWithdraw.processWithdraw, self.withdrawCache.user is called back in self.withdrawCache.user.call{value: address(this).balance}("") after updated state:

function processWithdraw(
GMXTypes.Store storage self
) external {
...
//@audit state changed
try GMXProcessWithdraw.processWithdraw(self) {
if (self.withdrawCache.withdrawParams.token == address(self.WNT)) {
self.WNT.withdraw(self.withdrawCache.tokensToUser);
​
//@audit called after state changed
(bool success, ) = self.withdrawCache.user.call{value: address(this).balance}("");
require(success, "Transfer failed.");
...
//@audit state called after reentrancy
self.tokenA.safeTransfer(self.withdrawCache.user, self.tokenA.balanceOf(address(this)));
self.tokenB.safeTransfer(self.withdrawCache.user, self.tokenB.balanceOf(address(this)));
​

If self.withdrawCache.user is a contract with receive function it can call contract back while it has inconsistent state
Function GMXWithdraw.processWithdraw with reentrancy can be called through external function with no nonReentrant modifier GMXVault.processWithdraw

Impact

Contract call while state is inconsistent possibility

Tools Used

Recommendations

Do not call user back when state is inconsistent, add nonReentrant modifier for functions can be affected by reentrancy

Updates

Lead Judging Commences

hans Lead Judge over 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

Reentrancy by keepers

Impact: High Likelihood: Low The only possible external caller is the keepers. But this is still a vulnerability and it is strongly recommended to implement CEI pattern. Given the limited impact, similar issues (reentrancy by keepers) are grouped.

Support

FAQs

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