MyCut

Description:

The constructor does not validate the length of the players and rewards arrays passed as input. These arrays are critical to the reward distribution logic, and any mismatch in their lengths can lead to serious issues such as out-of-bounds errors or incorrect mapping of rewards to players. Without this validation, the contract can be deployed in an inconsistent state, where some players might not receive rewards, or rewards might be incorrectly assigned.

https://github.com/Cyfrin/2024-08-MyCut/blob/946231db0fe717039429a11706717be568d03b54/src/Pot.sol#L22-L35

Impact:

Failure to validate the lengths of the players and rewards arrays could result in the following:

• Inconsistent State: If the lengths differ, some players may not receive rewards, or the rewards might not be accurately assigned.

• Potential for Out-of-Bounds Errors: Accessing an index in the rewards array that does not exist could result in out-of-bounds errors during deployment or execution.

• Unintended Behavior: The contract may not function as intended, leading to mistrust from users and potential financial losses.

Proof of Concept:

1. Deploy the contract with mismatched players and rewards arrays:

   address[] memory players = new address[](2);

   players[0] = 0xAddress1;

   players[1] = 0xAddress2;

   ​

   uint256[] memory rewards = new uint256[](1);

   rewards[0] = 1000;

   ​

   IERC20 token = IERC20(0xTokenAddress);

   new Pot(players, rewards, token, 1000);

2. Observe that the contract is deployed without any errors, despite the mismatch in array lengths.

3. When trying to access the reward for the second player, the reward might be incorrect or might not be set at all.

Recommended Mitigation:

Implement a check in the constructor to ensure that the lengths of the players and rewards arrays match before proceeding with the rest of the logic. This ensures that each player is correctly mapped to their corresponding reward:

Example Fix:

This validation ensures that the contract is deployed in a consistent state, with each player correctly mapped to their intended reward, preventing any potential out-of-bounds errors or misallocation of rewards.