First Flight #18: T-Swap

Summary

This report summarizes the findings of a security audit conducted on the PoolFactory contract. The main focus is on uninitialized state variables identified by the Slither static analysis tool. The audit highlights the presence of uninitialized mappings s_pools and s_tokens which are used in multiple functions within the contract.

Vulnerability Details

Uninitialized State Variables

Description

The following state variables are never initialized and are used in critical functions:

• s_pools (src/PoolFactory.sol#27)

  • Used in:

    • PoolFactory.createPool(address) (src/PoolFactory.sol#47-58)

    • PoolFactory.getPool(address) (src/PoolFactory.sol#63-65)

• s_tokens (src/PoolFactory.sol#28)

  • Used in:

    • PoolFactory.getToken(address) (src/PoolFactory.sol#67-69)

Exploit Scenario

An uninitialized state variable in Solidity is implicitly initialized to zero. In the case of mappings, this means that any key not explicitly set will return zero. This could lead to incorrect assumptions in the logic of the contract and potential vulnerabilities if these mappings are relied upon for critical functionality.

For example, if the s_pools mapping is used to verify the existence of a pool, an uninitialized mapping could falsely indicate the non-existence of a pool, leading to the unintended creation of duplicate pools.

Impact

The impact of uninitialized state variables in the PoolFactory contract is potentially high, as it could lead to:

• Incorrect verification of pool existence, potentially causing the creation of duplicate pools.

• Logical errors in the retrieval of token or pool addresses, affecting the integrity of the pool management system.

• Loss of funds or denial of service if functions relying on these mappings behave unexpectedly.

Tools Used

• Slither

Recommendations

To mitigate the risks associated with uninitialized state variables, the following steps are recommended:

1. Explicit Initialization: Explicitly initialize all state variables, even if they are meant to start with a zero value. This improves code readability and ensures that no variable is left unintentionally uninitialized.

   mapping(address => address) private s_pools = {};

   mapping(address => address) private s_tokens = {};

2. Initialization in Constructor: Ensure that any necessary initial state is set up in the contract constructor.

3. Validation Checks: Add additional validation checks in functions that rely on these mappings to ensure that they contain the expected values before proceeding with operations.

   function createPool(address tokenAddress) external returns (address) {

   require(tokenAddress != address(0), "Invalid token address");

   require(s_pools[tokenAddress] == address(0), "Pool already exists");

   // Rest of the function

   }

Reference: Slither Detector Documentation: Uninitialized State Variables