Core Contracts

Impact

The burn function in the Debt Token contract is documented to return a tuple with the following order:

1. Scaled tokens burned

2. New total supply after burning

3. Underlying tokens burned

4. Balance increase due to interest

However, the implementation returns the tuple as (underlying amount burned, total supply, scaled tokens burned, balance increase). This discrepancy causes the caller to misinterpret the values, resulting in incorrect debt accounting. As the protocol uses these values to update user balances and to adjust interest rates, the misinterpretation lead to significant errors in debt calculation enabling financial exploitation such as over- or under-burning of tokens, misrepresentation of user debt

Proof of Concept

• Affected Code (Debt Token burn function):
  DebtToken.sol#213

  // Documentation states:

  // @return A tuple containing:

  // - uint256: The amount of scaled tokens burned

  // - uint256: The new total supply after burning

  // - uint256: The amount of underlying tokens burned

  // - uint256: The balance increase due to interest

  ​

  // Actual implementation:

  return (amount, totalSupply(), amountScaled, balanceIncrease);

• Caller Code Usage:
  LendingPool.sol#416

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

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

  Observation: The caller expects the first returned value (amountScaled) to be the normalized (scaled) amount, but it instead receives the underlying amount burned. Similarly, the third value (amountBurned) incorrectly receives the scaled amount.

• Vulnerability Trigger:
  This misalignment in return values will cause the protocol to update debt balances

• incorrectly. Such errors in the debt accounting mechanism leads to discrepancies in user debt records

Tools Used

Manual Review

Recommended Mitigation Steps

1. Align Return Values with Documentation:
   Modify the burn function to return values in the correct documented order. For instance, change the return statement to:

   return (amountScaled, totalSupply(), amount, balanceIncrease);

   This ensures that:

   • The first value is the scaled tokens burned.

   • The third value is the underlying tokens burned.

2. Update Documentation and Caller Logic (if needed):
   Alternatively, if the implementation is intended to be as-is, update both the documentation and all callers to correctly interpret the returned values. However, the recommended approach is to fix the return order to match the intended design.