The program allows the update authority to set any non negative cooldown value, including i64::MAX, through Set(UpdateCoolDownPeriod). Later, unstake computes withdrawable_timestamp using checked addition between the current unix timestamp and cool_down_period_s. If the cooldown is set too large, this addition overflows and unstake fails with CoolDownOverflow, preventing creation of new pending withdrawals. This is a privileged misconfiguration issue rather than an unprivileged exploit, but it is still a real correctness problem in the current logic. A fix would be to enforce a sane upper bound on cooldown values when processing Set(UpdateCoolDownPeriod) instead of only checking that the value is non negative.
The program allows the update authority to set any non negative cooldown value, including
i64::MAX, throughSet(UpdateCoolDownPeriod). Later,unstakecomputeswithdrawable_timestampusing checked addition between the current unix timestamp andcool_down_period_s. If the cooldown is set too large, this addition overflows andunstakefails withCoolDownOverflow, preventing creation of new pending withdrawals. This is a privileged misconfiguration issue rather than an unprivileged exploit, but it is still a real correctness problem in the current logic. A fix would be to enforce a sane upper bound on cooldown values when processingSet(UpdateCoolDownPeriod)instead of only checking that the value is non negative.