stake.link

Summary

Malicious user can frontrun transfer functions to prevent any locks from being transferred.

Vulnerability Details

In SDLPoolSecondary, there is a condition queuedLockUpdates[_lockId].length must be zero before any account can transfer a lock.

queuedLockUpdates[_lockId].length is updated when initiateUnlock() is called or when _queueLockUpdate() is called.

A malicious user can always queue a lock update or initiate an unlock before transfer is called, reverting the transfer function. Queueing an update is easier than initiating an unlock because the user can just call extendLockDuration() without any consequences.

Impact

Locks cannot be transferred.

Tools Used

VSCode

Recommendations

Have a lock system in place, such that when the owner activates the lock, no initiate unlock or extend lock functions can be done. The owner can then clear all the existing queuedLockUpdates, and then enable transfers. This system may cause more centralization issues, however.

There will also be the case where the transfer cannot be called, even without malicious user, simply because there is high traffic to extend lock and initiate unlock. The transfer function should be made to be more flexible than currently intended.