Closed c4-bot-6 closed 5 months ago
Any liquidation over a pool that does not have enough tokens in it's balance to to pay the liquidator will be blocked
that seems to be like a desired functionality by design and expected behavior. @vonMangoldt can confirm
GalloDaSballo marked the issue as primary issue
Any liquidation over a pool that does not have enough tokens in it's balance to to pay the liquidator will be blocked
that seems to be like a desired functionality by design and expected behavior. @vonMangoldt can confirm
no i think hes right from my first looking into it. Just curious why it didnt dos in our javascript tests. Probably the percentage roundings etc need to be aligned for that behaviour
GalloDaSballo marked the issue as sufficient quality report
I would suggest downgrading to medium since as a liquidator you can always find a rounding where it still works which is annoying but it means the general funcitonality still works and no user funds at risk etc. Still a good find 👍 (For an example take a look at javascript test extra functionality2 : it("Liquidator get right amount if shares when pool has not enough token") @GalloDaSballo
@GalloDaSballo please mark this as disagree with severity
(add label)
trust1995 marked issue #116 as primary and marked this issue as a duplicate of 116
trust1995 marked the issue as satisfactory
trust1995 changed the severity to 2 (Med Risk)
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseCore.sol#L493-L499 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L229-L232
Vulnerability details
It is stated in the documentation of the contest from the c4 site that liquidations are rounded against the liquidator when it will evaluate the amount of tokens they need to payback related to the borrowshares they payoff. This becomes a problem when the amount that will be liquidated will be bigger then the amount of tokens that are available in the pool, when this happens the liquidation process logic will get in the function _withdrawOrAllocateSharesLiquidation which it's role is to cashout all the possible tokens from the pool and if that amount is not enough it will also give some shares to the liquidator. Now, the problem comes from the fact that totalPoolInShares will be rounded down because variable _maxSharePrice is selected as false, while totalPoolToken is not rounded down and represents the actual(real) amount of tokens that are in the pool. After that when the function _coreWithdrawBare is called and those 2 values will be used to update pseudoTotalPool and totalDepositShares ( using functions _decreasePseudoTotalPool and _decreaseTotalDepositShares ) the variables pseudoTotalPool and totalDepositShares will not be synced anymored as one is updated with a rounded down value and the other one with a real value. The variable totalDepositShares will be bigger then pseudoTotalPool and this becomes a problem in _syncPoolAfterCodeExecution because it will determine that lendingSharePriceAfter is smaller then lendingSharePriceBefore breaking the invariant and reverting the liquidation transaction.
Impact
Any liquidation over a pool that does not have enough tokens in it's balance to to pay the liquidator will be blocked
Proof of Concept
Run the test from below using command
The output of the test
We can clearly observe that lendSharePriceAfter is smaller then lendSharePriceBefore and this is why the transaction is reverted with the error InvalidAction.
Tools Used
Manual Review
Recommended Mitigation Steps
When you are calculating the value of totalPoolInShares round up the value turning _maxSharePrice to true.
Assessed type
DoS