stake.link

Summary

In _transfer of SDLPoolSecondary, doesn't handle case when queued updates cannot be processed which could lock tokens.

Vulnerability Details

The _transfer function in SDLPoolSecondary handles transferring reSDL NFTs between accounts.

It does not properly validate if a user has any queued update operations before transferring: SDLPoolSecondary.sol#_transfer

If a user has queued updates that cannot be processed (due to invalid state on primary chain), tokens could get locked as transfers will always revert.

As you can see, before transferring the token, it checks if there are any queued updates for that _tokenId in the queuedLockUpdates mapping.

If there are queued updates present, it will revert the transaction with the CannotTransferWithQueuedUpdates error.

This means that if a user has a "stale" queued update that can never be processed, all future transfer calls will revert. This could potentially lead to a permanent locking of that user's tokens and a loss of access to their funds.

Impact

If transfers revert due to a "stale" queued operation, it could:

• Permanently lock user's tokens

• Lead to loss of access to their funds

Example scenario leading to unprocessable queued updates

1. User queues operation

2. Primary chain state renders it invalid

3. Queued operation can never execute

4. Any token transfer will now revert

Tools Used

Manual Review

Recommendations

Ensure tokens remain accessible in all cases by handling edge cases in transfer logic.

1. Delete/invalidate stale queue entries

2. Allow withdrawal/transfers independent of queue

3. Support admin purge of faulty queue entries

This would help ensure users do not lose access to tokens in case of issues processing the queue.