sherlock-audit / 2022-11-float-capital-judging

2 stars 1 forks source link

zimu - Potential reentrancy vulnerability #49

Closed sherlock-admin closed 1 year ago

sherlock-admin commented 1 year ago

zimu

unlabeled

Potential reentrancy vulnerability

Summary

Reentrancy in MarketExtendedCore._addPoolToExistingMarket(IMarketExtendedCore.SinglePoolInitInfo,uint256,address,uint32) (contracts/market/template/MarketExtended.sol#117-159)

Vulnerability Detail

State variables are written after the call(s). Thus, Hacker may re-entry the calls without state changes.

External calls:

IPoolToken(initPool.token).initialize(initPool,seederAndAdmin,_marketIndex,uint8(_numberOfPoolsOfType[uint256(initPool.poolType)])) (contracts/market/template/MarketExtended.sol#139)

IPoolToken(initPool.token).mint(MARKET_SEEDER_DEAD_ADDRESS,initialActualLiquidityForNewPool) (contracts/market/template/MarketExtended.sol#141)

State variables written after the call(s): require(bool,string)(_numberOfPoolsOfType[uint256(initPool.poolType)] ++ == poolInfo.poolTier,incorrect pool tier) (contracts/market/template/MarketExtended.sol#148)

Impact

Medium or High

Code Snippet

See Vulnerability Detail

Tool used

Manual Review

Recommendation

Let the state variables written before the call(s)

JasoonS commented 1 year ago

In this example this function can only be called by adminOnly so no re-entrancy would be possible unless 'admin' is compromised. No explination of what the attacker could do with this in any case.

The poolToken that recieves the external call is controlled/defined by us.