Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roll back withdraw and deposit logic #84

Merged
merged 7 commits into from
Sep 22, 2023
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 2 additions & 27 deletions src/MetaMorpho.sol
Original file line number Diff line number Diff line change
Expand Up @@ -368,44 +368,19 @@ contract MetaMorpho is ERC4626, Ownable2Step, IMetaMorpho {

/// @dev Used in mint or deposit to deposit the underlying asset to Blue markets.
function _deposit(address caller, address owner, uint256 assets, uint256 shares) internal override {
// If asset is ERC777, `transferFrom` can trigger a reentrancy BEFORE the transfer happens through the
// `tokensToSend` hook. On the other hand, the `tokenReceived` hook, that is triggered after the transfer,
// calls the vault, which is assumed not malicious.
//
// Conclusion: we need to do the transfer before we mint so that any reentrancy would happen before the
// assets are transferred and before the shares are minted, which is a valid state.
// slither-disable-next-line reentrancy-no-eth
SafeERC20.safeTransferFrom(IERC20(asset()), caller, address(this), assets);
super._deposit(caller, owner, assets, shares);

_supplyMorpho(assets);

_mint(owner, shares);

emit Deposit(caller, owner, assets, shares);
}

/// @dev Used in redeem or withdraw to withdraw the underlying asset from Blue markets.
function _withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares)
internal
override
{
if (caller != owner) {
_spendAllowance(owner, caller, shares);
}

// If asset is ERC777, `transfer` can trigger a reentrancy AFTER the transfer happens through the
// `tokensReceived` hook. On the other hand, the `tokensToSend` hook, that is triggered before the transfer,
// calls the vault, which is assumed not malicious.
//
// Conclusion: we need to do the transfer after the burn so that any reentrancy would happen after the
// shares are burned and after the assets are transferred, which is a valid state.
_burn(owner, shares);

require(_withdrawMorpho(assets) == 0, ErrorsLib.WITHDRAW_FAILED_MORPHO);

SafeERC20.safeTransfer(IERC20(asset()), receiver, assets);

emit Withdraw(caller, receiver, owner, assets, shares);
super._withdraw(caller, receiver, owner, assets, shares);
}

/* INTERNAL */
Expand Down
2 changes: 1 addition & 1 deletion test/forge/ERC4626Test.sol
Original file line number Diff line number Diff line change
Expand Up @@ -178,7 +178,7 @@ contract ERC4626Test is BaseTest {
assets = bound(assets, deposited + 1, type(uint256).max / (deposited + 10 ** DECIMALS_OFFSET));

vm.prank(ONBEHALF);
vm.expectRevert("ERC20: burn amount exceeds balance");
vm.expectRevert(bytes(ErrorsLib.WITHDRAW_FAILED_MORPHO));
Rubilmax marked this conversation as resolved.
Show resolved Hide resolved
vault.withdraw(assets, RECEIVER, ONBEHALF);
}

Expand Down
Loading