StakingRewards.setRewardsDuration allows setting near zero or enormous rewardsDuration, which breaks reward logic

[code423n4]

Lines of code

https://github.com/code-423n4/2022-09-y2k-finance/blob/ac3e86f07bc2f1f51148d2265cc897e8b494adf7/src/rewards/StakingRewards.sol#L225-L232

Vulnerability details

Impact

Similar to code-423n4/2022-02-concur-findings#223.
notifyRewardAmount will be inoperable if rewardsDuration bet set to zero. If will cease to produce meaningful results if rewardsDuration be too small or too big.

Proof of Concept

The setter do not control the value, allowing zero/near zero/enormous duration:

https://github.com/code-423n4/2022-09-y2k-finance/blob/ac3e86f07bc2f1f51148d2265cc897e8b494adf7/src/rewards/StakingRewards.sol#L225-L232

Division by the duration is used in notifyRewardAmount:

https://github.com/code-423n4/2022-09-y2k-finance/blob/ac3e86f07bc2f1f51148d2265cc897e8b494adf7/src/rewards/StakingRewards.sol#L189-L195

Tools Used

None

Recommended Mitigation Steps

Check for min and max range in the rewardsDuration setter, as too small or too big rewardsDuration breaks the logic

[HickupHH3]

While the finding is valid,

• if the rewardsDuration is set to zero, the loss of functionality of notifyRewardAmount has no impact on funds nor existing rewards. function can be called again to re-set its value. one can also view it as a way to prevent further reward distributions
• if the rewardsDuration is too big: "will cease to produce meaningful results" is a very vague description. More details need to be provided on this: it can cause rewardsRate to be zero, thus bricking reward distribution.

Because the former point has minimal impact while the latter lacks a crucial step in explaining the adverse impact of failing reward distributions, I have to downgrade the issue to QA.

User's primary QA.