Core Contracts

Summary

Lending pool have mechanism where if there are excess amount of asset token from the desiredBuffer, then the excess would be sent into the curve vault. But this function would fail because the function would deposit the asset token from LendingPoolinto the curve vault, but the asset token are saved inside the RToken contract address, not in the LendingPool contract itself.

Vulnerability Details

lets take a look in LendingPool::

LendingPool.sol#L772-L793

notice that the currentBuffervalue is actually the asset token held inside the reserve.reserveRTokenAddress not this contract.

so if the if currentBuffer > desiredBuffer is satisfied, the function would then call _depositIntoVaultwith the excess.

LendingPool.sol#L799-L803

it try to approve the curveVault address to spend excess amount, but the deposit function would revert because there are no token asset inside this lending pool contract that can be sent. thus making this function revert with insufficient balance.

Impact

1. potential DoS for function that call the faulty _rebalanceLiquiditylike LendingPool's deposit, withdraw, and repay

2. DoS cant be stopped by setting the curve vault to address(0) to make the function _rebalanceLiquidityto return early, because setCurveVaultaddress params cant be set to address zero.

3. unused asset token inside RToken cannot generate yield, making the protocol and user lose potential yield generated from the curve vault.

Tools Used

manual review

Recommendations

set the asset approval for LendingPool to spent token held by RToken address, then apply the following diff so before the deposit happen the asset token is sent into the lending pool first: