FV-SOL-5 Logic Errors

TLDR

Logic errors arise from mistakes in the program’s control flow or conditional statements. These errors usually occur when the code’s behavior deviates from its intended purpose, not because of a flaw in the underlying arithmetic but due to a conceptual mistake in implementing rules or boundaries

Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract VulnerableMarket {
    uint256 constant BLOCK_EPOCH = 100000;
    mapping(uint256 => uint256) public cantoPerBlock; // Reward rates by epoch
    struct MarketInfo {
        uint256 lastRewardBlock;
        uint256 accCantoPerShare;
    }
    mapping(address => MarketInfo) public marketInfo;

    constructor() {
        cantoPerBlock[0] = 100;       // Reward for epoch 0-99999
        cantoPerBlock[BLOCK_EPOCH] = 0; // No reward for epoch 100000+
    }

    function update_market(address _market) public {
        MarketInfo storage market = marketInfo[_market];
        if (block.number > market.lastRewardBlock) {
            uint256 i = market.lastRewardBlock;
            while (i < block.number) {
                uint256 epoch = (i / BLOCK_EPOCH) * BLOCK_EPOCH;
                // Incorrect: should be `epoch + BLOCK_EPOCH`
                // Adding BLOCK_EPOCH to i only creates a fixed offset from i. It moves i forward by 100,000 blocks from whatever its current position is. However, this new position could land anywhere within an epoch and will not necessarily align with the start of the next epoch boundary
                uint256 nextEpoch = i + BLOCK_EPOCH; 
                uint256 blockDelta = min(nextEpoch, block.number) - i;

                // Incorrect reward calculation across epochs
                market.accCantoPerShare += blockDelta * cantoPerBlock[epoch];
                i += blockDelta;
            }
            market.lastRewardBlock = block.number;
        }
    }

    function min(uint256 a, uint256 b) internal pure returns (uint256) {
        return a < b ? a : b;
    }
}

Classifications

Boundary Misalignment (FV-SOL-5-C1)

Occurs when code fails to respect predefined boundaries or intervals (e.g., epochs, time windows, thresholds)

Incorrect Conditionals (FV-SOL-5-C2)

Results from incorrect conditions in if statements, loops, or switches, causing unintended branching in code execution

e.g. a function meant to handle reward calculation might incorrectly check for block.number >= lastRewardBlock instead of block.number > lastRewardBlock, causing rewards to be skipped or duplicated

Improper State Transitions (FV-SOL-5-C3)

A contract that has a specific progression (e.g., setup, running, paused) may mistakenly allow state-changing functions to execute out of order, leading to potential exploitation

Misordered Calculations (FV-SOL-5-C4)

Errors from improper indexing or referencing in mappings, often due to incorrect key choices or updates

Event Misreporting (FV-SOL-5-C5)

Failing to emit an event during a critical update like reward distribution, making it hard to track transactions or actions on-chain

Mitigation Patterns

State Machine Design (FV-SOL-5-M1)

The State Machine Design mitigation pattern is a robust approach for managing complex workflows or processes with defined states

Fail-Safe Defaults (FV-SOL-5-M2)

Use safe defaults in case of unexpected conditions or edge cases

Unit Testing on Edge Cases (FV-SOL-5-M3)

Implement exhaustive tests for each function, focusing on boundary values, extreme inputs, and edge cases

Actual Occurrences

• https://solodit.cyfrin.io/issues/h-02-eth-gets-locked-in-the-groupcoinfactory-contract-pashov-audit-group-none-groupcoin-markdown

Content

https://www.linkedin.com/pulse/state-machine-design-pattern-insolidity-luis-soares-m-sc-/