Calls to Chainlink Oracle could potentially revert, which may result in a complete Denial-of-Service of the protocol since it relies heavily on the oracle to get the prices of assets. For example when a user wants to create a limit short or when a bidder wants to place a bid, the Chainlink Oracle is used to determine the price of the asset.
Call to latestRoundData could potentially revert. Feeds cannot be changed after they are configured so this would result in a permanent denial of service. Even though the asset oracle can be changed by the owner, the baseOracle variable in the AppStorage library cannot be changed and is set only when deploying. Chainlink’s multisigs can immediately block access to price feeds at will. Therefore, to prevent denial of service scenarios, it is recommended to call Chainlink Oracle using a defensive approach with Solidity’s try/catch structure. In this way, if the call to the price feed fails, the caller contract is still in control and can handle any errors safely and explicitly.
The protocol checks for a zero roundId and wrong timestamp or price but what if the call reverts. Then it will not even go to the baseOracleCircuitBreaker to determine whether or not to use the backup option - Uniswap TWAP.
Even though this is highly unlikely for more used feeds this could potentially happen and the impact will be high.
Denial-of-Service of the protocol and funds of the users locked
Manual Review and Chainlink docs
Surround the call to latestRoundData() with try/catch instead of calling it directly. In a scenario where the call reverts, the catch block can be used to call the fallback oracle or handle the error in any other suitable way.
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.