Core Contracts

Summary

In the LendingPool::_repay function, an unscaled amount (amountBurned in underlying asset units) is incorrectly subtracted from a scaled balance (user.scaledDebtBalance in DebtToken units), leading to incorrect debt accounting.

Vulnerability Details

The vulnerability exists in the debt balance update:

The issue occurs because:

• user.scaledDebtBalance tracks debt in scaled units (DebtToken units)

• amountBurned is meant to be returned from the burn function in underlying asset units

• Subtracting unscaled from scaled units breaks unit consistency

• Results in incorrect debt reduction

The correct implementation should be:

Here, scaledAmount should be the scaled version of the amount parameter passed into the function, rather than amountScaled, which is returned from DebtToken::burn.

Reasoning:

• amountScaled includes accumulated interest, making it larger than scaledAmount.

• The interest component should not be subtracted from the user's principal debt balance.

• Using amountScaled would incorrectly reduce the debt by more than the intended repayment amount, leading to inconsistent accounting.

By ensuring that only scaledAmount (the scaled version of amount) is deducted, we maintain accurate debt tracking and prevent unintentional over-reductions.

A similar issue exists in LendingPool::finalizeLiquidation:

Issue:

When a liquidator finalizes a user's liquidation, the debt balance is updated incorrectly. The value being subtracted, amountBurned, is in underlying asset units, whereas user.scaledDebtBalance is stored in scaled units.

Why is This Incorrect?

• amountBurned includes accrued interest, making it larger than the actual scaled debt repayment.

• Since scaledDebtBalance represents debt in scaled units, it should only be reduced by the correctly scaled version of the repaid amount.

• Failing to do so results in inconsistent debt tracking, potentially leading to accounting errors or over-reduction of a user’s debt.

Correct Approach:

The scaled version of userDebt should be used instead:

Where scaledAmount represents the original debt repayment amount in scaled units, excluding any accrued interest. This ensures precise and accurate debt updates in the protocol.

Potential for Economic Exploits

• Arbitrage Opportunities: An attacker might manipulate repayment transactions to reduce their debt balance more than they should, effectively exploiting the miscalculation.

• Bad Debt Accumulation: If debt isn’t reduced correctly, the protocol could inadvertently allow for an accumulation of bad debt, which can compromise its financial stability.

• Protocol Integrity: Since debt accounting is central to many financial protocols, such an error can undermine trust and lead to significant financial losses if exploited.

Impact

• Incorrect Debt Balances: As a result, user debt balances can become inaccurate—either under- or over-reported—which can destabilize the overall accounting of the protocol.

• System Invariants at Risk: Because the total system debt is tracked based on these individual balances, a miscalculation can lead to a breakdown in the protocol’s internal consistency, potentially allowing discrepancies that attackers could exploit.

• Unit Inconsistency: The error arises from subtracting an unscaled burn amount (measured in underlying asset units) directly from a debt balance that is maintained in scaled (DebtToken) units. This mismatch means the debt is not reduced correctly.

Tools Used

Manual Review