A critical storage collision vulnerability exists in the upgrade mechanism between LevelOne and LevelTwo contracts. The storage layout mismatch during the upgrade process leads to severe data corruption and potential loss of critical state variables.
The vulnerability stems from inconsistent storage layouts between the two contracts. LevelOne contains several state variables that are missing in LevelTwo, including:
schoolFees
reviewTime
reviewCount
lastReviewTime
When upgrading from LevelOne to LevelTwo, the storage slots shift to fill these gaps, causing:
Direct value corruption (e.g., bursary value changes from 15,000 USDC to 2419201)
Mapping corruption (student scores become corrupted)
Array data loss (student and teacher lists become empty)
Constant value changes (teacher wage changes from 35% to 40%)
The storage collision has severe consequences:
Financial Impact: Bursary amounts are corrupted, potentially leading to incorrect fund distribution
Data Loss: All student and teacher records are lost
Access Control: Teacher and student status mappings are corrupted
Business Logic: Different constant values (TEACHER_WAGE vs TEACHER_WAGE_L2) lead to incorrect calculations
Contract State: The entire contract state becomes unreliable after upgrade
Manual code review
Foundry for testing
results in
Maintain consistent storage layout between upgradeable contracts:
Keep all state variables from the previous version
Add new variables at the end of the storage layout
Use storage gaps to prevent collisions
Add storage layout checks in the upgrade function to verify compatibility
Consider implementing a migration function to properly transfer state between versions
Add comprehensive tests that verify storage layout compatibility before allowing upgrades
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.