Core Contracts

Summary

The StabilityPool contract is designed to be an upgradable contract using OpenZeppelin’s upgradeable libraries. However, it inherits ReentrancyGuard, which is not designed for upgradability. This can cause serious issues during future upgrades, including storage layout corruption and reentrancy protection failures.

Vulnerability Details

OpenZeppelin’s ReentrancyGuard contract relies on a storage variable (_status) to track reentrant calls.

• In standard contracts, ReentrancyGuard works correctly because storage variables maintain their positions.

• However, upgradable contracts use proxy patterns where storage layouts must remain consistent across upgrades.

• Since ReentrancyGuard is not upgradeable, it does not use the correct storage slot assignment mechanisms needed for upgradable contracts.

• This means future contract upgrades could lead to:

  1. Storage Slot Conflicts: If an upgrade adds new state variables before _status, it might overwrite the storage used by ReentrancyGuard, breaking its functionality.

  2. Reentrancy Protection Failure: If storage gets misaligned, _status may not be properly initialized, leading to reentrancy vulnerabilities after upgrades.

  3. Unexpected Contract Behavior: If ReentrancyGuard's _status variable gets altered due to an upgrade, it could lead to locked contract functions or unrestricted reentrancy, depending on the corruption.

Impact

• Loss of Reentrancy Protection: The contract could become vulnerable to reentrancy attacks after an upgrade.

• Potential Contract Lock: If _status is corrupted, functions using nonReentrant could permanently revert.

• Undefined Behavior: Storage misalignment could cause unpredictable contract behavior.

Tools Used

Manual review

Recommendations

Replace ReentrancyGuard with ReentrancyGuardUpgradeable, which is designed to be used with upgradable contracts.