The StabilityPool contract inherits from ReentrancyGuard instead of ReentrancyGuardUpgradeable while being an upgradeable contract. This can lead to storage collisions and potential contract corruption during upgrades.
The contract is designed to be upgradeable as shown by its inheritance of Initializable, OwnableUpgradeable, and PausableUpgradeable. However, it uses the non-upgradeable version of ReentrancyGuard:
This creates a potential issue because the non-upgradeable ReentrancyGuard uses fixed storage slots that could collide with the storage layout of the upgradeable contract pattern.
The current contract is deployed with the following inheritance:
Initializable
ReentrancyGuard (non-upgradeable)
OwnableUpgradeable
PausableUpgradeable
When the contract is upgraded:
The non-upgradeable ReentrancyGuard storage layout remains fixed
New storage variables could potentially collide with the ReentrancyGuard's storage slot
This could corrupt the reentrancy guard's state variable
Potential storage collisions during contract upgrades
Possible corruption of the reentrancy guard's state
Risk of reentrancy attacks if the guard's state is corrupted
Contract upgrades could become unsafe or impossible
Manual code review
Replace the non-upgradeable ReentrancyGuard with its upgradeable counterpart.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.