Reentracy

[Jayfromthe13th]

Impact Severity: Medium to low Detection of the reentrancy bug. Do not report reentrancies that involve Ether (see reentrancy-eth). Vulnerability Untrusted external contract calls could callback leading to unexpected results such as multiple withdrawals or out-of-order events. Example of vulnerability:

function bug(){
        require(not_called);
        if( ! (msg.sender.call() ) ){
            throw;
        }
        not_called = False;
  }  

Lines affected: –Reentrancy in GameInstance.processRound(uint112,uint128,uint128) (contracts/game/GameInstance.sol#298-336): External calls:

• _processFees(currentRoundData,settlementPrice,processingRoundIndex) (contracts/game/GameInstance.sol#333)
  • yoloWalletContract.returnLiquidity(lpAddress,returnAmount,totalFees) (contracts/game/GameInstance.sol#607) State variables written after the call(s):
• _startRound(startTime,nextStrikePrice,newRoundIndex) (contracts/game/GameInstance.sol#335)
  • currentRoundData.startTime = startTime (contracts/game/GameInstance.sol#496)
  • currentRoundData.lpFeeRate = lpFeeRateU16 (contracts/game/GameInstance.sol#497)
  • currentRoundData.strikePrice = strikePrice (contracts/game/GameInstance.sol#498)

—Reentrancy in LiquidityPool.mintInitialShares(uint256) (contracts/core/LiquidityPool.sol#135-160): External calls:

• stablecoinTokenContract.safeTransferFrom(sender,address(walletContract),initialAmount) (contracts/core/LiquidityPool.sol#142-146) State variables written after the call(s):
• _mint(sender,initialAmount * adjustmentFactor) (contracts/core/LiquidityPool.sol#157)
  • _balances[account] += amount (node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol#263)
• _mint(sender,initialAmount * adjustmentFactor) (contracts/core/LiquidityPool.sol#157)
  • _totalSupply += amount (node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol#262)

—Reentrancy in LiquidityPool.mintLpShares(uint256) (contracts/core/LiquidityPool.sol#167-187): External calls:

• stablecoinTokenContract.safeTransferFrom(sender,address(walletContract),depositAmount) (contracts/core/LiquidityPool.sol#174-178) State variables written after the call(s):
• _mint(sender,newShareAmount) (contracts/core/LiquidityPool.sol#184)
  • _balances[account] += amount (node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol#263)
• _mint(sender,newShareAmount) (contracts/core/LiquidityPool.sol#184)
  • _totalSupply += amount (node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol#262)

—Reentrancy in WhitelistSFTClaims.claimNft() (contracts/accessory/WhitelistSFTClaims.sol#94-116): External calls:

• usdcContract.transferFrom(sender,address(this),10e6) (contracts/accessory/WhitelistSFTClaims.sol#101)
• yoloNFTPackContract.mintBaseSFT(sender) (contracts/accessory/WhitelistSFTClaims.sol#103) State variables written after the call(s):
• claimeesRegister[sender] = 0 (contracts/accessory/WhitelistSFTClaims.sol#115)

---Reentrancy in ERC1155SemiFungible._mintNFT(address,uint256,string) (contracts/tokens/extensions/ERC1155SemiFungible.sol#323-360): External calls:

• super._mint(to,id,UNITY,EMPTY_BYTES) (contracts/tokens/extensions/ERC1155SemiFungible.sol#356)
  • IERC1155Receiver(to).onERC1155Received(operator,from,id,amount,data) (node_modules/@openzeppelin/contracts/token/ERC1155/ERC1155.sol#476-484) State variables written after the call(s):
• _setURI(id,newURI) (contracts/tokens/extensions/ERC1155SemiFungible.sol#358)
  • _uris[id] = newUri (contracts/tokens/extensions/ERC1155DynamicURI.sol#91)

Recommendation Apply the check-effects-interactions pattern and/or reentrancy guard.

[CryptoKiddies]

Thanks for keeping us on the ball! The reentrancy vulnerabilities exist only when a smart contract wallet (or any sc) receives a direct call from another contract caller. None of the call stacks generated in these examples send data directly to a user/smart wallet and therefore are not subject to reentrancy callbacks. Rather, these contracts belong to the YOLO smart contracts system-with the exception of USDC token, and all make state changes within their respective scopes, or at most, calls within YOLOrekt domain. If we were to send data on transfer, then this would become an issue. For example, if we utilized the ERC1155Receiver and sent data to a receiver wallet, then this would become highly relevant.

Regardless, we'll take another look and if changes are needed, there will be a reward coming your way:)