Lines of code

https://github.com/code-423n4/2024-07-karak/blob/ab18e1f6c03e118158369527baa2487b2b4616b1/src/entities/SlasherLib.sol#L94-L124 https://github.com/code-423n4/2024-07-karak/blob/ab18e1f6c03e118158369527baa2487b2b4616b1/src/entities/SlasherLib.sol#L126-L151

Vulnerability details

Impact

It can lead to failed slashing attempts and differences between expected and actual slashed amount.

Proof of Concept

The problem stems from the time delay between requesting and finalizing a slashing operation.

In the requestSlashing function:

function requestSlashing(
    CoreLib.Storage storage self,
    IDSS dss,
    SlashRequest memory slashingMetadata,
    uint256 nonce
) external returns (QueuedSlashing memory queuedSlashing) {
    // ...
    uint256[] memory earmarkedStakes = fetchEarmarkedStakes(slashingMetadata);
    queuedSlashing = QueuedSlashing({
        // ...
        earmarkedStakes: earmarkedStakes,
        // ...
    });
    // ...
}

The earmarkedStakes are calculated based on the current total assets of the vault.

In the finalizeSlashing function:

function finalizeSlashing(CoreLib.Storage storage self, QueuedSlashing memory queuedSlashing) external {
    // ...
    if (queuedSlashing.timestamp + Constants.SLASHING_VETO_WINDOW > block.timestamp) {
        revert MinSlashingDelayNotPassed();
    }
    // ...
    for (uint256 i = 0; i < queuedSlashing.vaults.length; i++) {
        IKarakBaseVault(queuedSlashing.vaults[i]).slashAssets(
            queuedSlashing.earmarkedStakes[i],
            self.assetSlashingHandlers[IKarakBaseVault(queuedSlashing.vaults[i]).asset()]
        );
    }
    // ...
}

The slashing is only executed after the SLASHING_VETO_WINDOW has passed. During this time window, the total assets in the vault could decrease, potentially leading to insufficient funds for slashing when finalizeSlashing is called.

Tools Used

Manual review

Recommended Mitigation Steps

Consider implementing a locking mechanism that prevents withdrawals or transfers of the earmarked assets during the veto window. Alternatively, recalculate the slashable amount at the time of finalization based on the current total assets, ensuring that the slashed amount is always proportional to the available assets. Then, implement checks in the finalizeSlashing function to handle cases where the available assets are less than the originally earmarked amount, possibly by slashing a percentage of the current assets rather than a fixed amount.

Assessed type

ETH-Transfer

code-423n4 / 2024-07-karak-findings

Insufficient Funds for Slashing Due to Time Delay Could Render Slashing Mechanism Ineffective #95