Core Contracts

Summary

The LendingPool contract in RAAC's codebase contains a potential bad debt accumulation issue. If a borrower's debt is partially covered during liquidation but not entirely repaid, the protocol does not handle the remaining debt properly. This could result in permanent bad debt accumulation, preventing further borrowing and disrupting the totalAssets and totalDebt calculations.

Vulnerability Details

1. Partial Repayment During Liquidation

   • The finalizeLiquidation() function allows the Stability Pool to cover the borrower's outstanding debt using its funds.

   • However, if the available liquidity is insufficient to fully repay the borrower’s outstanding debt, the remaining portion is not correctly accounted for or socialized (distributed across the system).

2. Debt Token Burn without Handling Residual Debt

   • The function burn() from IDebtToken is called to remove the debt:

     (uint256 amountScaled, uint256 newTotalSupply, uint256 amountBurned, uint256 balanceIncrease) =

     IDebtToken(reserve.reserveDebtTokenAddress).burn(userAddress, userDebt, reserve.usageIndex);

     ​

   • If amountBurned < userDebt, the remaining debt is not removed or adjusted in total debt tracking.

3. Implications

   • Perpetual Bad Debt: The unhandled debt remains in the system, preventing full liquidation.

   • Broken Accounting: The totalDebt calculation becomes inconsistent, blocking new borrow operations.

   • Liquidation Fails for Some Users: If the protocol relies on full liquidation to remove defaulted borrowers, failing to account for residual debt leaves "zombie" accounts.

Example Attack Scenario

• Step 1: A borrower takes a loan of 1000 crvUSD, backed by NFT collateral.

• Step 2: Due to market volatility, the borrower’s health factor falls below the liquidation threshold.

• Step 3: The Stability Pool attempts liquidation, but only 600 crvUSD is available.

• Step 4: The system does not properly account for the remaining 400 crvUSD debt.

• Step 5: This unaccounted debt remains in reserve.totalUsage, affecting interest calculations and blocking future borrowing.

Attack Scenario

• Step 1: A borrower takes a loan of 1000 crvUSD, backed by NFT collateral.

• Step 2: Due to market volatility, the borrower’s health factor falls below the liquidation threshold.

• Step 3: The Stability Pool attempts liquidation, but only 600 crvUSD is available.

• Step 4: The system does not properly account for the remaining 400 crvUSD debt.

• Step 5: This unaccounted debt remains in reserve.totalUsage, affecting interest calculations and blocking future borrowing.

Severity: High

• Impact: Affects core lending protocol logic, potentially locking the lending system.

• Likelihood: Moderate, as it requires partial liquidation with insufficient Stability Pool reserves.

Impact

Perpetual Bad Debt: The unhandled debt remains in the system, preventing full liquidation.

Broken Accounting: The totalDebt calculation becomes inconsistent, blocking new borrow operations.

Tools Used

Manual Review

Recommendations

Handle Remaining Debt in Liquidation

• Adjust totalUsage to reflect any unpaid debt after liquidation.