FV-SOL-6 Unchecked Returns

TLDR

Failure to check returns is a surprising pitfall to many smart contracts. Not checking returns properly could cause unexpected behavior leading to security issues as a result.

Code

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

contract VulnerableUncheckedCall {
    mapping(address => uint256) public balances;

    // Allows users to deposit Ether into the contract
    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    // Vulnerable withdraw function with an unchecked external call
    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");

        balances[msg.sender] -= amount;

        // Unchecked call to send Ether to the sender
        // Vulnerability: If this call fails, the contract does not handle it,
        // resulting in potential issues for the user
        (bool success, ) = msg.sender.call{value: amount}("");
        
        // The return value of the call is unchecked, so the contract assumes the transfer succeeded
    }
}

Classifications

Unchecked External Call Return (FV-SOL-6-C1)

functions like delegatecall, call, staticcall, send, and external contract function calls fail but return values go unchecked, leading to unintended state changes, lost funds, or incorrect assumptions about success

Unchecked Transfer Return (FV-SOL-6-C2)

ailing to check the return value of calls to transferFrom or transfer functions on ERC20 tokens can lead to unexpected behavior. For certain tokens, these functions may return false instead of reverting when there are insufficient tokens or if the transfer is unsuccessful. If the return value is ignored, the transaction might continue even if the transfer failed

Silent Fail (FV-SOL-6-C3)

A function call fails without detection, and continues executing as if it succeeded, which can create an invalid or inconsistent state

False Positive Success Assumption (FV-SOL-6-C4)

The contract assumes a function call succeeded without verifying, potentially leading to state inconsistencies or incorrect balance assumptions if the call actually failed

Partial Execution with No Rollback (FV-SOL-6-C5)

When a function call fails mid-function, the contract may continue execution without rolling back previous changes, leading to partial, unintended state changes

False Contract Existence Assumption (FV-SOL-6-C6)

If a contract does not verify that an external address is a valid contract, it may perform operations under the incorrect assumption that the contract exists, risking failed calls

Mitigation Patterns

Checked Returns FV-SOL-6-M1)

It is generally a good strategy to ensure that all returns in your contract has at least minimal checks for validity, success and expected return values

Checks-Effects-Interactions(FV-SOL-6-M2)

This pattern ensures that all internal changes are made (checks and effects) before any external calls are made, reducing reentrancy risks and ensuring contract state integrity before interactions

Actual Occurrences

• https://solodit.cyfrin.io/issues/m-11-unchecked-return-value-of-low-level-calldelegatecall-code4rena-nextgen-nextgen-git

• https://solodit.cyfrin.io/issues/lack-of-contract-existence-check-on-delegatecall-may-lead-to-unexpected-behavior-trailofbits-yield-v2-pdf

• https://solodit.cyfrin.io/issues/h-03-result-of-transfer-transferfrom-not-checked-code4rena-spartan-protocol-spartan-protocol-contest-git

Content