The LSTRewardsSplitter::performUpkeep function correctly enforces a constraint that prevents users from calling _splitRewards() unless the newRewards value is greater than or equal to the controller.rewardThreshold(). However, this same restriction is not enforced in the LSTRewardsSplitter::splitRewards function, which can be used to achieve the same outcome. The lack of consistent enforcement allows a griefer to split rewards prematurely, potentially causing the protocol to miss out on any benefits of letting rewards build up.
The performUpkeep function includes a condition that ensures _splitRewards() is only called when newRewards is greater than or equal to the rewardThreshold():
However, the splitRewards function does not enforce this same threshold and allows rewards to be split as long as newRewards is not zero:
The lack of a threshold check in splitRewards creates a vulnerability where an attacker or griefer can call the function prematurely, splitting rewards before they accumulate to a sufficient level. This prevents the protocol from achieving any potential advantages from allowing rewards to build up, such as minimizing gas costs for reward distribution or achieving higher reward thresholds.
A malicious user can grief the system by calling splitRewards before rewards reach the intended rewardThreshold, forcing premature reward distributions..
Manual
Enforce Consistent Constraints: Apply the same rewardThreshold() check in the splitRewards function that is present in performUpkeep. This will ensure that rewards are only split when they reach the required threshold, preventing premature distributions.
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.