This report identifies a critical logical omission in the graduateAndUpgrade() function of the LevelOne.sol contract. The function, which authorizes the system upgrade to a new version (e.g., LevelTwo.sol), fails to verify essential student prerequisites before doing so. Specifically, it does not check if all enrolled students have received the required number of reviews (e.g., 4 reviews as per implied documentation and session structure). Authorizing an upgrade without these checks allows the system to advance even if students have not met fundamental participation or academic requirements, contradicting the intended operational rules and potentially leading to an inconsistent state for the subsequent contract version.
The graduateAndUpgrade() function in LevelOne.sol is responsible for concluding a school session, distributing funds, and authorizing an upgrade to a new contract implementation.
The project's operational intent, as understood from documentation and typical school system logic, includes prerequisites for students before a session is considered fully complete and ready for an upgrade. A key prerequisite is that students should have received a full set of reviews (e.g., one per week for a 4-week session, totaling 4 reviews).
The graduateAndUpgrade() function currently calls _authorizeUpgrade(_levelTwo) without performing any checks on the listOfStudents to ensure that each student has met such prerequisites. For instance, it does not iterate through students to verify their reviewCount (which itself has a bug of not being incremented in giveReview, but assuming that bug is fixed, this check is still missing).
While the actual filtering of students based on cutOffScore is intended for the LevelTwo.sol contract's graduate() reinitializer, system-wide readiness conditions, such as all students having completed their review cycle, should ideally be met before the LevelOne.sol contract authorizes an upgrade.
Setup:
The LevelOne.sol contract is initialized, and a session is started.
Students are enrolled.
Some students receive fewer than the expected 4 reviews by the end of the session (e.g., a student only receives 2 reviews).
Execution:
The principal calls graduateAndUpgrade(levelTwoAddress, "") after the session duration has passed.
The function performs payout calculations.
_authorizeUpgrade(levelTwoAddress) is called and succeeds (as it only checks if the caller is the principal).
Payouts are executed.
Outcome:
The system is authorized for an upgrade to LevelTwo.sol despite some students not having completed their review cycle (e.g., not having 4 reviews).
The LevelTwo.sol contract's graduate() reinitializer will then operate on a student body where not all participants have met the implicit prerequisites of LevelOne.sol.
The impact of this missing check is High:
Violation of Core Academic/Operational Rules: The system fails to enforce a fundamental rule that students must complete their review cycle before the system progresses. This undermines the integrity of the academic process.
Inconsistent State for Upgraded Contract: The LevelTwo.sol contract might inherit a state where students are at different stages of completion than expected, potentially complicating its graduation logic or leading to unfair outcomes.
Misleading System Progression: The system signals readiness for an upgrade (by authorizing it) even when underlying conditions are not met.
Reduced Trust and Fairness: If students can progress or be considered for graduation without fulfilling all requirements, it can be perceived as unfair and reduce trust in the system's rules.
Manual Code Review
Implement checks for essential student prerequisites within the graduateAndUpgrade() function before calling _authorizeUpgrade(). The most critical missing check is verifying that all students in listOfStudents have received the required number of reviews (e.g., 4).
All students are graduated when the graduation function is called as the cut-off criteria is not applied.
All students are graduated when the graduation function is called as the cut-off criteria is not applied.
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.