c4-bot-9 commented 4 months ago

Lines of code

https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L1514

Vulnerability details

Vulnerability detail

In PanopticPool#_getPremia() function, premiumAccumulatorsByLeg variable is initalized as below:

    uint256[2][4] memory premiumAccumulatorsByLeg

Which mean that it only can handle maximum 2 legs:

    for (uint256 leg = 0; leg < numLegs; ) {   //<---
        uint256 isLong = tokenId.isLong(leg);
        if ((isLong == 1) || computeAllPremia) { //long là nó deposit vào
            LiquidityChunk liquidityChunk = PanopticMath.getLiquidityChunk(
                tokenId,
                leg,
                positionSize
            );
            uint256 tokenType = tokenId.tokenType(leg);

            (premiumAccumulatorsByLeg[leg][0], premiumAccumulatorsByLeg[leg][1]) = SFPM.getAccountPremium(   //<----

From documentation at here, one TokenId can have maximum 4 legs inside, so if the tokenId have 3 or 4 legs, this function will be reverted, which will make some action cant be done like burning (because _updateSettlementPostBurn() call _getPremia() function)

Impact

TokenId cant be burned. Which mean it can not be liquidated or burn by owner

Tools Used

Manual review

Recommended Mitigation Steps

Upgrade this variable to:

        uint256[4][2] memory premiumAccumulatorsByLeg

Assessed type

Other

c4-judge commented 4 months ago

Picodes marked the issue as primary issue

dyedm1 commented 4 months ago

There are 4 legs, each with two tokens. The order has been confused here.