Core Contracts

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

Incorrect implementation of getUserDebt() method in LendingPool.sol

Summary

incorrect implementation of LendingPool::getUserDebt() may lead to lesser debt amount than than are supposed to be.

Vulnerability Details

User debt is recorded in state variable UserData[userAddress].scaledDebtBalance, where this amount is the debtToken minted, not the real debt value. The real debt value is calculated from multiplying reserve debt index. However the code implemented in LendingPool::getUserDebt() does this by multiplying last time updated usageIndex, while it should be the in time index:

function getUserDebt(address userAddress) public view returns (uint256) {
UserData storage user = userData[userAddress];
return user.scaledDebtBalance.rayMul(reserve.usageIndex); //@audit
}

instead it should be :

function getUserDebt(address userAddress) public view returns (uint256) {
UserData storage user = userData[userAddress];
return user.scaledDebtBalance.rayMul(getNormalizedDebt()); //@audit
}

while in most occasions, there will be a reserve index updating before any token actions(deposti/withdraw/repay), which will result in no differences of NormalizedDebt() and reserve.usageIndex.

Hovever In StabilityPool::liquidateBorrower(), userDebt is straightly calculated from lendingPool.getUserDebt(), which will results in less debt that users accumulated.

Impact

users get less debt than real time accumulated

Tools Used

manual

Recommendations

consider change getUserDebt() to :

function getUserDebt(address userAddress) public view returns (uint256) {
UserData storage user = userData[userAddress];
return user.scaledDebtBalance.rayMul(getNormalizedDebt()); //@audit
}
Updates

Lead Judging Commences

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

LendingPool::getNormalizedIncome() and getNormalizedDebt() returns stale data without updating state first, causing RToken calculations to use outdated values

Support

FAQs

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