Code Correctness: Reentrancy

A function breaks the Checks-Effects-Interaction pattern or fails to safeguard against reentrancy attacks.

A reentrancy attack occurs when a malicious contract calls back into the calling contract before the first invocation is finished. This happens when the vulnerable contract exposes a function that interacts with external contracts before locally carrying out the effect of the current call. This can lead to the external contract taking over the control flow of the interaction.

If a malicious contract calls the exposed function of a victim that unsafely interacts back with the calling contract, then the attacking contract will receive and process the interaction (via a fallback function for example) and immediately call back the victim's exposed function again in order to enter a call-interact-call loop. This recursive state prevents any further code in the victim to be executed and can lead to partial or total draining of assets or values depending on the nature of the interaction.

The Checks-Effects-Interaction pattern is commonly used in smart contracts to prevent incorrect logic. The pattern designates that the code first check any required conditions, then carry out the related state change (the effect) and finally interact with the external contract in relation to that effect.

Example 1: The following example allows a reentrancy attack by performing a check, interaction, and then effect, not adhering to the Checks-Effects-Interaction pattern.

The code:

1. Checks the balance of the sender (Checks).
2. Sends out Ether to the caller via msg.sender.call.value (Interaction).
3. Performs a state change by decreasing the balance of the sender (Effects).

function withdraw(uint amount) public{
    if (credit[msg.sender] >= amount) {
        require(msg.sender.call.value(amount)());
        credit[msg.sender]-=amount;
    }
}

The code in Example 1 breaks the Checks-Effects-Interaction pattern by doing Checks-Interaction-Effects instead. This can lead to reentrancy if an attacking smart contract receives the Ether in a fallback function and immediately calls back withdraw, creating a recursive situation where Ether is drained because the line of code that decreases the balance (aka the Effect) never gets executed.