Core Contracts

Vulnerability Details

The repayment process contains a critical mismatch between the DebtToken::burn() function return values and their handling in the LendingPool::_repay(). The return tuple order is inverted between scaled/unscaled amounts, leading to:

1. Incorrect Asset Transfers

   Scaled amount (protocol's internal accounting units) used instead of actual asset amount

2. Wrong Debt Balance Updates

   Scaled values treated as raw amounts, permanently corrupting user positions

3. Protocol Insolvency Risk

   Mismatch between actual assets and accounting records

_repay()

Impact

1. Permanent loss of repaid funds

2. Users unable to reduce actual debt

3. Protocol accounting becomes unreliable

4. Liquidation mechanisms break completely

5. Protocol insolvency within hours of exploitation

Proof of Concept

DebtToken::burn() Return Values :

LendingPool::_repay() Incorrect Assignment :

Example Scenario

1. User repays 100 crvUSD (raw amount)2. Scaled amount = 100 / 1.1e27 = ~90.9e-273. DebtToken returns:

• BurnedAmount = 100

• scaledAmount = 90.9e-27

1. LendingPool incorrectly:

• Transfers 100 crvUSD (should transfer 90.9e-27)

• Records debt reduction as 90.9e-27 (should reduce by 100)

Result:

• Protocol loses 99.999...% of repaid amount

• User debt remains nearly unchanged

• Total supply becomes inconsistent

Recommendations

Fix Return Value Handling