Core Contracts

Summary

The RToken contract's burn function suffers from two critical flaws: incorrect ordering of return values and double scaling of the burn amount when a user burns their entire balance. These issues can lead inaccurate data reporting, potential inconsistent accounting within the contract and denail of service to the last user trying to withdraw their funds.

Vulnerability Details

The burn function in the RToken contract has the following issues:

• Incorrect Return Value Order: The function returns a tuple of (uint256, uint256, uint256). The intended order is (amountScaled, newTotalSupply, amount). However, the current implementation returns (amount, newTotalSupply, amount). This means the first return value, which should be the scaled amount burned, is actually the unscaled amount.

• Burn Function

  function burn(

  address from,

  address receiverOfUnderlying,

  uint256 amount,

  uint256 index

  ) external override onlyReservePool returns (uint256, uint256, uint256) {

  // ... other code ...

  ​

  return (amount, totalSupply(), amount); // Incorrect: Should be (amountScaled, totalSupply(), amount)

  }

• Double Scaling: When a user burns their entire balance, the amount is equal to their scaled balance. The code then calculates amountScaled by multiplying amount by the index. Since the user's balance is already scaled, this multiplication results in double scaling.

  uint256 userBalance = balanceOf(from);

  ​

  if(amount > userBalance){

  amount = userBalance;

  }

  // scaled up amount

  uint256 amountScaled = amount.rayMul(index); // Double scaling if amount == userBalance

Impact

Due to the incorrect return value from RToken, ReserveLibrary.withdraw function calls updateInterestRatesAndLiquidity function with wrong amount underlying tokens. This causes totalLiquidity in the reserve to be less than the total liquidity taken causing revert with InsufficientLiquidity. Thus any last user trying to withdraw will not be able to withdraw their funds + interest due to the incorrect return amount of underlying tokens.

Proof of Concept

1. Alice deposits 100_000 tokens into the RToken contract.

2. TotalLiquidity is updated to 100_000 tokens.

3. After some time, Alice's balance is scaled to 110_000 tokens.

4. Alice calls withdraw with amount = 110_000 tokens (scaled balance).

5. The burn function returns (110_000, totalSupply(), 110_000).

6. Now the totalLiquidity is 100_000 tokens, and the liquidityTaken is 110_000 tokens.

7. As the liquidityTaken is greater than totalLiquidity, the updateInterestRatesAndLiquidity function reverts with InsufficientLiquidity.

Proof of Code

1. Use this guide to intergrate foundry into your project: foundry

2. Create a new file FortisAudits.t.sol in the test directory.

3. Add the following gist code to the file: Gist Code

4. Run the test using forge test --mt test_FortisAudits_IncorrectBurnScalingInRToken -vvvv.

Logs before the fix:

Logs after the fix:

Recommended Mitigation

To fix the burn function, the return values should be corrected to (amountScaled, newTotalSupply, amount). Additionally, the double scaling issue can be resolved by directly using the amount value when the user burns their entire balance.