Skip to content

Latest commit

 

History

History
83 lines (60 loc) · 3.36 KB

070.md

File metadata and controls

83 lines (60 loc) · 3.36 KB

Glamorous Plum Baboon

Medium

Improper Use of uint256 for Booleans

Summary

Certain functions (setActive, setFrozen, and setPaused) use uint256 variables to represent boolean values. This design choice introduces potential risks as values other than 0 or 1 can lead to unexpected behavior. Specifically, invalid values such as 2 or other non-zero integers could cause logical errors in the contract.

Description

The ReserveConfiguration contract utilizes uint256 variables to represent boolean states, which is unnecessary and introduces risk. For instance, the following logic is applied to set the state of the active flag:

(uint256(active ? 1 : 0) << IS_ACTIVE_START_BIT_POSITION);

The use of a uint256 here for a boolean is not only non-intuitive but can lead to issues where the value is mistakenly set to something other than 0 or 1. A malicious actor or a logical flaw in the contract could exploit this design choice, leading to unexpected outcomes or undefined behavior.

Root Cause

Improper representation of boolean states using uint256 variables.

Line of Code (LoC) where it occurs:

(uint256(active ? 1 : 0) << IS_ACTIVE_START_BIT_POSITION);

Affected functions:
i, setActive ii, setFrozen iii, setPaused

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/configuration/ReserveConfiguration.sol#L172-L176

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/configuration/ReserveConfiguration.sol#L192-L196

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/configuration/ReserveConfiguration.sol#L212-L217

Impact

The primary impact of this issue is undefined or unexpected behavior of the contract when invalid values (e.g., 2 or greater) are used for state flags. This could result in:
i, Incorrect state transitions. ii, Logical flaws in the execution of dependent functions.
iii, Potential vulnerabilities for malicious actors to exploit the unexpected behavior of the contract.

Proof of Concept (PoC)

Below is a simplified demonstration of the potential issue:

contract StateTest {
    uint256 public state;

    function setActive(uint256 value) public {
        // Expecting only 0 or 1, but no validation is done
        state = value;
    }

    function isActive() public view returns (bool) {
        // Returns true for any non-zero value, including invalid ones like 2
        return state != 0;
    }
}

// PoC
StateTest test = new StateTest();
test.setActive(2); // Invalid value
require(test.isActive() == true, "Invalid state accepted");

Recommended Mitigation

To avoid this issue, it is recommended to explicitly use the bool type for boolean flags instead of uint256. This approach eliminates the risk of invalid values being used.

Example mitigation:

function setActive(bool active) public {
    uint256 state = active ? 1 : 0;
    // Use explicit boolean checks
}

Additionally, the contract should:

  1. Validate input values for functions that depend on these flags to ensure only 0 or 1 is accepted.
  2. Add consistent comments explaining the bit layout and purpose of each mask for clarity and maintainability.