Insolvent user could avoid liquidation due to logic error

[c4-bot-1]

Lines of code

https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/libraries/PanopticMath.sol#L241-L268
https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L1450-L1452
https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L1017-L1171

Vulnerability details

Impact

Available possibility for loss of funds, due to unexpected liquidation DoS

Proof of Concept

At the end of PanopticMath::twapFilter, the tick at sortedTicks[10] is returned, which isn't at the median of sortedTicks with 19 length, which leads to permanent returning of higher tick than actual.

There are 2 main scenarios which could occur due to bad indexation:

1. When liquidator executes PanopticPool::liquidate, the function could revert unexpectedly due to (Math.abs(currentTick - twapTick) > MAX_TWAP_DELTA_LIQUIDATION) won't pass, because of currentTick - twapTick is going to be higher than it is supposed to be (if actualTwapTick > currentTick).
2. During the execution of PanopticPool::liquidate, PanopticPool::_getSolvencyBalances is called to compute the balanceCross and thresholdCross.

function _getSolvencyBalances(
        LeftRightUnsigned tokenData0,
        LeftRightUnsigned tokenData1,
        uint160 sqrtPriceX96
    ) internal pure returns (uint256 balanceCross, uint256 thresholdCross){
        unchecked {
            // the cross-collateral balance, computed in terms of liquidity X*√P + Y/√P
            // We use mulDiv to compute Y/√P + X*√P while correctly handling overflows, round down
            balanceCross =
                Math.mulDiv(uint256(tokenData1.rightSlot()), 2 ** 96, sqrtPriceX96) +
                Math.mulDiv96(tokenData0.rightSlot(), sqrtPriceX96);
            // the amount of cross-collateral balance needed for the account to be solvent, computed in terms of liquidity
            // overstimate by rounding up
            thresholdCross =
                Math.mulDivRoundingUp(uint256(tokenData1.leftSlot()), 2 ** 96, sqrtPriceX96) +
                Math.mulDiv96RoundingUp(tokenData0.leftSlot(), sqrtPriceX96);
        }
    }

The third parameter from the input is the sqrtPrice at the twapTick. Due to the logic error the sqrtPrice is permanently going to be higher than actual, because of this the chases of (balanceCross >= thresholdCross) check to revert are permanently increased (if tokenData0.rightSlot() > tokenData0.leftSlot()).

Tools Used

Recommended Mitigation Steps

Rewrite the end of the function to get the median value from 9th index instead of 10th

function twapFilter(IUniswapV3Pool univ3pool, uint32 twapWindow) external view returns (int24) {
        ...
        ...
        ...
            // Get the median value
+++         return int24(sortedTicks[9]);
---         return int24(sortedTicks[10]);
        }
    }

Assessed type

Other

[c4-judge]

Picodes marked the issue as duplicate of #239

[c4-judge]

Picodes marked the issue as not a duplicate

[c4-judge]

Picodes marked the issue as duplicate of #421

[c4-judge]

Picodes changed the severity to QA (Quality Assurance)

[c4-judge]

Picodes marked the issue as grade-a