Liquid Staking

Summary

A Denial of Service (DoS) vulnerability exists in the StakingPool::deposit function, which prevents the PriorityPool::_deposit function from successfully staking assets and minting liquid staking tokens (LST). This occurs because the StakingPool::deposit function attempts to transfer LINK tokens from the PriorityPool, but it does not have the required approval to move the assets. As a result, the call consistently reverts, breaking the deposit functionality of the protocol.

Vulnerability Details

The issue arises when the PriorityPool::_deposit function calls StakingPool::deposit to stake asset tokens (LINK) and mint LST tokens. However, StakingPool::deposit attempts to transfer LINK tokens from the caller (which is PriorityPool) to itself without first obtaining the necessary approval to transfer those tokens.

The code snippet in question:

The token.safeTransferFrom(msg.sender, address(this), _amount); line attempts to transfer LINK tokens from msg.sender, which is the PriorityPool. However, StakingPool has not been given approval to transfer assets from the PriorityPool's balance. This results in the safeTransferFrom call consistently reverting, preventing deposits from being processed.

Impact

This issue breaks a critical functionality of the protocol, as users are unable to deposit assets into the PriorityPool. Without the ability to deposit, the protocol cannot stake tokens or mint LST tokens, which disrupts the entire staking operation and renders the protocol unusable for new deposits.

Tools Used

Manual

Recommendations

Update the contract to ensure that StakingPool has the necessary approval to transfer LINK tokens from the PriorityPool. This can be done by either giving StakingPool the appropriate allowance from PriorityPool or redesigning the function to handle the token transfer in a different way. Ensuring proper approval will prevent the function from reverting and restore deposit functionality.