Core Contracts

## Summary

In the current implementation of the repay function, there is a critical issue when users attempt to repay more than their outstanding debt. If a user’s repayment amount exceeds their debt balance, the function scales the repayment amount down to the user’s actual debt balance but fails to account for the correct total debt. As a result, the system only transfers a fraction of the required repayment, causing an imbalance where the user burns all their debt tokens but does not fully repay their loan. This leads to a protocol loss where the system is underpaid by a large amount.

## Vulnerability Details

• Problem:

  • The repay function allows users to repay debt by burning debt tokens. When the user specifies an amount higher than their actual debt, the amount is capped at their debt balance.

  • The issue arises when the amount to be burned is scaled and the final repayment amount of debt does not match the user’s total debt.

  • The debt scaling is done using the user's balance x usageIndex, and the burn function scales down the repayment amount to the user's debt token balance, not their total debt (which is debt balance multiplied by usageIndex).

  • Therefore, the amount transferred to the system is incorrect, and the user burns all their debt tokens without actually repaying the full amount they owe, leading to a discrepancy in the system's balance.

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

  IDebtToken(reserve.reserveDebtTokenAddress).burn(onBehalfOf, amount, reserve.usageIndex);

  ​

  @> incorrect value is passed in safetransferFrom Feteched From burn return value AmountScaled

  IERC20(reserve.reserveAssetAddress).safeTransferFrom(msg.sender, reserve.reserveRTokenAddress, amountScaled);

• Example Scenario:

  • Let’s assume the user has a debt balance of 1,000 tokens with a usageIndex of 2. This means their total debt is 2,000 tokens (1,000 * 2).

  • If the user tries to repay 2,000 tokens, the repay function will scale the amount down to the user’s debt token balance, which is 1,000 tokens.

  • However, the system will only transfer 1000 tokens (which is half of the user's debt token balance) to the reserve, leaving a loss of 1,000 tokens in the protocol.

  • Additionally, the debt tokens are burned entirely, leaving the user with no debt tokens, making it impossible to fully repay their loan.

## Impact

• Financial Loss to the Protocol:

  • The protocol could lose significant funds due to users burning all their debt tokens without fully repaying their loans. This creates a discrepancy between the amount owed and the amount paid.

• Inconsistent Debt Representation:

  • The system's debt state will be inconsistent, as users can end up burning all their debt tokens without fulfilling their debt obligations. This can lead to liquidity shortages and risks of insolvency.

## Tools Used

• Code review of the repay function and debt-burning mechanism.

## Recommendations

1. Ensure Full Debt Repayment:

   if user is trying to burn all there debt tokens means completely close there borrow position, then the user debt should be scaled to there totalDebt, which can be either find by assign it to userDebt variable or calculate using Scaledbalance x UsgaeIndex.

   Example Fix:

   uint256 userDebt = IDebtToken(reserve.reserveDebtTokenAddress).balanceOf(onBehalfOf);

   or

   uint256 actualRepayAmount = ScaledBalance * reserve.usageIndex; // Ensure total debt is considered

   or

   IERC20(reserve.reserveAssetAddress).safeTransferFrom(msg.sender, reserve.reserveRTokenAddress, userDebt/actualRepayAmount);