Core Contracts

Summary

A vulnerability exists in the _rebalanceLiquidity() function of the LendingPool contract, where it incorrectly assumes that excess reserve tokens are already in the custody of LendingPool. However, all reserve tokens are held in RToken.sol. This discrepancy leads to deposit(), withdraw() and borrow() reverts, in addition to preventing excess funds from being deposited into the Curve Vault to generate additional yield.

Vulnerability Details

The _rebalanceLiquidity() function is designed to deposit excess reserve tokens into the Curve Vault when the buffer exceeds the desired level:

LendingPool.sol#L778-L785

The problem arises because currentBuffer refers to reserve tokens held by RToken.sol, not directly by LendingPool. However, the function assumes that the excess tokens are already available for immediate deposit.

In the current implementation:

LendingPool.sol#L799-L803

Since LendingPool does not have custody of the excess reserve tokens, this results in failed deposits and potentially reverts during liquidity rebalancing.

Impact

1. Failed Excess Token Deposits: Excess reserve tokens remain idle in RToken.sol instead of being deposited into the Curve Vault, preventing the protocol from earning yield on those assets.

2. Inefficient Capital Utilization: Protocol on behalf of users lose out on potential yield generation, leading to long-term inefficiencies in the protocol’s performance.

3. Reverts in Deposit, Withdraw and Borrow Functions: The _rebalanceLiquidity() function is embedded within LendingPool.deposit(), LendingPool.withdraw() and LendingPool.borrow(). If the excess token transfer logic fails, these calls could revert, directly affecting user operations and leading to potential denial of service for lending/liquidity management.

Tools Used

Manual

Recommendations

Consider making the following refactoring:

LendingPool.sol#L782-L785