Core Contracts

Summary

The StabilityPool::_depositIntoVault function deposits tokens into the vault using the asset balance of the pool rather than pulling tokens from the correct source (i.e. the rToken contract). This causes an incorrect source of funds during liquidity rebalancing and may lead to transaction failures.

Vulnerability Details

The function is implemented as follows

When a user deposits assets, the funds are sent to the reserve’s rToken contract. The _rebalanceLiquidity function calculates the current buffer based on the balance of the reserve asset at the rToken’s address:

If the current buffer is above the desired level, excess funds are to be deposited into the vault by calling _depositIntoVault. However, the function attempts to pull tokens from the lending pool’s own balance (using reserve.reserveAssetAddress), not from the rToken contract where the assets actually reside. This mismatch in the expected source causes deposits to fail—as demonstrated by the following PoC—from the wrong sender.

Proof Of Concept
Place this under the
describe("Deposit and Withdraw", function () {
line in LendingPool.test.js

execute with npx hardhat test --grep "it fails when a crv vault is provided because of wrong sender to the vault"

Impact

• Liquidity Rebalancing Failure: Deposits to the vault may revert if sufficient funds are not available from the lending pool contract’s balance.

• Inaccurate Fund Accounting: The mismatch leads to incorrect liquidity tracking and can disturb the protocol’s balance between the lending pool and the vault.

Tools Used

• Manual Code Review

• Unit Testing (Foundry/Hardhat)

Recommendations

Modify the deposit logic to source funds correctly from the rToken’s balance rather than the lending pool contract. For example, instead of using the balance from reserve.reserveAssetAddress within the lending pool, use the rToken’s transfer function to move the assets from its own balance to the vault.