search

code-423n4 / 2023-11-kelp-findings

13 stars 11 forks source link

When the DepositPool is deployed and `rsETH.totalsupply()>0` and the contract will remain dosed #233

Closed c4-submissions closed 10 months ago

c4-submissions commented 11 months ago

Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTOracle.sol#L78 https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/RSETH.sol#L19

Vulnerability details

Impact

Their can be state where the token is already being used but the depositPool is not used yet and it will cause dos. User under the amount minted will be dosed. The protocol might have to chip in some funds to get the contract in unstuck state.

Proof of Concept

The dos can happen on state where the contracts are deployed and totalETHInPool =0 but rsETH.totalsupply>0 This can happen in a few ways.

  1. minter mints some tokens before the deployment to give out rewards or to get the liquidity pool started after this happen ths minter is swithced to the contract ex: rsETH.totalsupply=10e18 User tries to transfers 5 cbETH -> depositPool 
    totalETHInPool / rsEthSupply;

    it will equal 0 causing a revert 

    rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice();

    Tools Used

Recommended Mitigation Steps

make sure that the protocol dosnt mint before the contract is deployed

Assessed type

DoS

c4-pre-sort commented 11 months ago

raymondfam marked the issue as insufficient quality report

raymondfam commented 11 months ago

The description in #62 renders the ratio non-zero always.

c4-pre-sort commented 11 months ago

raymondfam marked the issue as primary issue

c4-judge commented 10 months ago

fatherGoose1 marked the issue as unsatisfactory: Invalid