StakeStone Vault

Chainlink oracles can return stale pricing data due to network delays or other issues. If stale data is used, transactions may execute with outdated prices, leading to incorrect LP valuations or withdrawals, potentially resulting in losses for users or the protocol. The current implementation does not check if the price data is stale.

Both `AssetVault.processWithdrawal(uint256 _index)` and `AssetVault.cancelWithdrawal(uint256 _index)` can pop elements from the `withdrawalRequests[]` array. If two calls are in the mempool at the same time, there is no guarantee that the respective `_index` will point to the intended `WithdrawalRequest`, as the opposing call may have modified the array. This can result in the incorrect withdrawal being processed/canceled.

When a user makes a withdrawal request, they specify a `_minReceiveAmount` of LP tokens to receive. When `WithdrawalQueue.processWithdrawals()` calls the `WithdrawalProcessor.callback()` function, `callback()` will call `AssetVault.requestWithdraw()` and `AssetVault.processWithdrawal()` to burn the LP tokens and send back the underlying token, after which the tokens are sent to the user. However, `AssetVault.processWithdrawal()` is not guaranteed to burn the LP tokens and transfer the underlying tokens. If `finalizedAmount < minReceiveAmount`, it cancels the withdrawal and returns the LP tokens to the `WithdrawalProcessor`. The `WithdrawalProcessor` falsely assumes that the call succeeded and approves the `WithdrawalQueue` to transfer `_minReceiveAmount` tokens to the user. If the `WithdrawalProcessor` has sufficient funds, then the withdrawal of `_minReceiveAmount` will be honored, irrespective of how large it is or what token prices currently are.

The `processWithdrawals()` function may be vulnerable to reentrancy when interacting with tokens that have callback functionality, such as ERC777 tokens. If a user crafts a withdrawal request with such a token, the request could be processed multiple times, allowing the fulfilling user to process the request multiple times. While this does not necessarily result in a loss for the protocol, it allows the fulfilling user to exploit the withdrawal process to their advantage by processing the withdrawal request multiple times.

In the `cancelWithdrawals()` function, it is possible to cancel a withdrawal receipt even after the withdrawal has been processed. The function only checks if the `receipt.deadline` has passed and if the caller is the requester, but it does not verify whether the withdrawal has already been completed (`isWithdrawn`). This can allow users to cancel a processed withdrawal receipt and emit the event `WithdrawalCancelled` which may impact off-chain components.