StakeStone security record

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 strategy manager may perform arbitrary calls on the `tokenAddr` contract by calling `invoke()`. This could be abused to request withdrawals and/or claim any queued withdrawals to oneself.

Some contracts contain setter functions that are only callable by the `StoneVault` or `StrategyController`. However, these setter functions are never called in the `StoneVault` or `StrategyController` contracts. If the configuration of the protocol changes, these contracts may not be updated accordingly. The following is a list of found functions: - `AssetVault.setNewVault()` - `Minter.setNewVault()` - `StrategyController.setNewVault()` - `SwappingAggregator.setSlippage()` - `SwappingAggregator.setUniRouter()` - `SwappingAggregator.setCurveRouter()` - `SwappingAggregator.setNewGovernance()`

The `removeUnderlyingAsset` function iterates through the entire `underlyingAssets` array without bounds checking, creating potential denial-of-service conditions. ```solidity uint256 length = underlyingAssets.length; uint256 i; for (i; i < length; i++) { if (underlyingAssets[i] == _asset) { underlyingAssets[i] = underlyingAssets[length - 1]; underlyingAssets.pop(); break; } } ``` If the array becomes very large, this function will run out of gas and become unusable.

In the `OracleRegistry` contract, the functions `getCutOffPrice()`, `getCutOffPrices()`, and `onlyGetCutOffPrices()` calculate a timestamp from `cutOffPriceUpdateAt` and then return `prices[_token][updatedAt]`. However, if no price was ever recorded for that (token, updatedAt) pair, for example, if the token was added after the cut-off update or removed before it then the mapping will return the default zero value.

In the `ParamRegistry` contract, the `setPriceUpdateInterval()` function enforces only a minimum bound but no maximum bound. Therefore, a privileged actor with the `D0_TIMELOCK_ROLE` can set the `_priceUpdateInterval` to an arbitrarily high value. This results in a denial-of-service scenario where all calls to `OracleRegistry.updatePrices` revert with `Errors.PriceUpdateTooFrequent()`. Additionally, consumers of prices that enforce freshness checks will eventually revert with `Errors.PriceValidityExpired()` since the maximum validity duration is capped at 7 days.

In the `Token` contract constructor, the `_admin` parameter is directly assigned the `DEFAULT_ADMIN_ROLE` via `_grantRole`. However, there is no validation to prevent `_admin` from being the zero address. If the contract is deployed with a zero address for the admin then all administrative access is lost permanently. This misconfiguration would prevent assignment of the `MINTER_ROLE` and block all future role management actions, effectively bricking minting functionality and governance control.

During creation of the `OracleRegistry` contract, the initial token oracles are checked against the stablecoin tolerance recorded in the `ParamRegistry` contract. However, this check is missing for oracles that are added or updated after contract initialization using the `updateTokenOracle()` and `addTokenOracle()` functions.