When the admin or manager calls the liquidateBorrower function, it will revert if the index of liquidity or usage is not updated.
To liquidate a borrower, they must first be added to the liquidation mapping in the lending pool contract. After the grace period expires, the admin/manager can call liquidateBorrower to proceed with liquidation.
However, this function will revert if the reserves are not updated, as it first calculates the debt amount the caller must pay on behalf of the liquidator to liquidate the borrower's position.
let have a look at liquidateBorrower function:
From the above code, it is evident that:
The scaledUserDebt amount is first calculated, and approval is given to the lending pool.
The updateState function is then called to update liquidityIndex and usageIndex.
The liquidation process first determines the amount the liquidator must pay before updating the indexes.If updateState modifies the indexes during execution, it can cause the transaction to revert.
Attackers can front-run liquidation calls, borrowing or repaying loans to ensure updateState modifies the usageIndex, triggering a reversion. Block stuffing can delay liquidation, causing repeated reverts, leading to an increasing debt burden.
Add following POC to file and run with command :npx hardhat test:
Note : In the above test case, I fast-forwarded time to ensure that updateState affects the usageIndex. However, any user can front-run this call or ensure that it gets executed in the next block.
Updating the state after calculation will result in a revert if the updateState function modifies the usageIndex.
Manual Review
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.