Alice has 100 LST which she wants to convert back to LINK tokens. She calls PriorityPool::withdraw() with _shouldUnqueue set to false and there are 80 LINK tokens judging from the value of totalQueued, this means that 20 will be queued for withdrawal such as here -> https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L679
This presents the following problem: how will those 80 tokens, that were used for exchange to LST, be claimed from the people that had their LINK queued in totalQueued. I do not see any function that actually makes that possible.
Alice has 100 LST and she wants to exchange them back to the LINK token due to personal reasons. If the contract of PriorityPool.sol has actually 100 tokens (totalQueued is used for tracking LINK tokens in this contract), then she can instantly withdraw them, otherwise whatever tokens are in the totalQueued are to be given momentarily, the rest going to be queued for a withdrawal when possible.
The issue in all of this stems from the following: if Alice calls PriorityPool::withdraw() willing to exchange all of her 100 LST tokens and totalQueued is let's say... 100 tokens for simplicity, she will actually be able to exchange LST -> LINK, but the users which had queued the 100 LINK tokens won't be able to claim the tokens that she had sent to the PriorityPool.sol. This is where the LST is send from Alice to PriorityPool.sol -> https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L312-L316.
Vulnerability in steps:
Alice has 100 LST and decides to call PriorityPool::withdraw() with _shouldUnqueue set to false
The 100 LST are transferred from her wallet to the PriorityPool.sol in https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L312-L316.
She claims her 100 LINK token successfully, but the users which had queued their token do not have any mechanism to claim the 100 LST that were deposited by Alice
Overtime, more and more LST is destined to be stuck in PriorityPool.sol with its current implementation causing loss of funds that were deposited by the users interacting with the protocol.
Manual review
Make a function that can claim LST.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.