Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: medium
Valid

The Withdraw event in ReserveLibrary emits incorrect values due to the incorrect return statement in the RToken's burn method

avoloder

Vulnerability Details

The Withdraw event in the ReserveLibrary should emit following values per its definition: the address of the user withdrawing, the amount withdrawn and the amount of liquidity tokens burned. In the following function we can see the current implementation:

function withdraw(
ReserveData storage reserve,
ReserveRateData storage rateData,
uint256 amount,
address recipient
) internal returns (uint256 amountWithdrawn, uint256 amountScaled, uint256 amountUnderlying) {
if (amount < 1) revert InvalidAmount();
​
// Update the reserve interests
updateReserveInterests(reserve, rateData);
​
// Burn RToken from the recipient - will send underlying asset to the recipient
(uint256 burnedScaledAmount, uint256 newTotalSupply, uint256 amountUnderlying) = IRToken(reserve.reserveRTokenAddress).burn(
recipient, // from
recipient, // receiverOfUnderlying
amount, // amount
reserve.liquidityIndex // index
);
amountWithdrawn = burnedScaledAmount;
// Update the total liquidity and interest rates
updateInterestRatesAndLiquidity(reserve, rateData, 0, amountUnderlying);
​
emit Withdraw(recipient, amountUnderlying, burnedScaledAmount);
---SNIPET---
}

We can see that the Withdraw event emits the values for recipient, amountUnderlying and burnedScaledAmount. The problem is that the value of burnedScaledAmount returned from ÌRToken::burn function is wrong as it can be seen from the function:

/**
* @notice Burns RToken from a user and transfers underlying asset
* @param from The address from which tokens are burned
* @param receiverOfUnderlying The address receiving the underlying asset
* @param amount The amount to burn (in underlying asset units)
* @param index The liquidity index at the time of burning
* @return A tuple containing:
* - uint256: The amount of scaled tokens burned
* - uint256: The new total supply after burning
* - uint256: The amount of underlying asset transferred
*/
function burn(
address from,
address receiverOfUnderlying,
uint256 amount,
uint256 index
) external override onlyReservePool returns (uint256, uint256, uint256) {
if (amount == 0) {
return (0, totalSupply(), 0);
}
​
uint256 userBalance = balanceOf(from);
​
_userState[from].index = index.toUint128();
​
if(amount > userBalance){
amount = userBalance;
}
​
uint256 amountScaled = amount.rayMul(index);
​
_userState[from].index = index.toUint128();
​
_burn(from, amount.toUint128());
​
if (receiverOfUnderlying != address(this)) {
IERC20(_assetAddress).safeTransfer(receiverOfUnderlying, amount);
}
​
emit Burn(from, receiverOfUnderlying, amount, index);
​
//@audit-issue should return amountScaled instead of amount
return (amount, totalSupply(), amount);
}

We can see that the function instead of returning amountScaled in the first place, it returns the same amount value two times, which is wrong since the amount value is not scaled by index.

Impact

The emitted events showing inaccurate logs causing the confusion and misleading users, damaging the overall realiability of the system

Tools Used

Manual Review

Recommendations

Inside RToken::burn function, return amountScaled in the first place instead of returning amount two times

return (amountScaled, totalSupply(), amount);

Updates

Lead Judging Commences

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RToken::burn returns incorrect underlying asset amount (amount instead of amountScaled), leading to wrong interest rate calculations

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RToken::burn returns incorrect underlying asset amount (amount instead of amountScaled), leading to wrong interest rate calculations

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!