stake.link

Summary

The function extend lock duration has no limit on the number of queues which could lead to a DOS on the extend lock duration function ans an inflation on the supply change

Vulnerability Details

In SDLPoolSecondary.sol the function extendLockDuration() can be cued an excessive number of times by a user by calling it consecutively with incrementing lock duration's. This could cause the user an excessive amount of gas to call the function executeQueuedOperations() after an update, it is possible for such a call to exceed the block gas limit. This can also cause an inflation in the supply change, due to multiple boost amount increments, the line in the function _queueLockUpdate() will be called multipe times:

queuedRESDLSupplyChange +=
int256(lockUpdate.lock.amount + lockUpdate.lock.boostAmount) -
int256(lock.amount + lock.boostAmount);

since the boost amounts for the updated lock are increasing inclusive of previous boost amounts, although only truly a single boost amount is effective. Theoretically this could lead to an overflow of the reSDLSupplyByChain variable in SDLPoolCCIPControllerPrimary.sol, however such is unlikely in practice due to a number of variables such as token decimals, max boost, update time and that uint256 is a really large number.

The root cause is the ability to call the extendLockDuration() function multiple times before an update.

Impact

Locked user funds.

Tools Used

Manual Review

Recommendations

I would recommend that a user be only allowed to cue a lock duration extension only once.