The last_block_number
variable is declared but not initialized in the constructor, defaulting to 0
. This could lead to undefined behaviour if accessed before being set.
The last_block_number
variable is used to track the block number of the most recent price update. However, it is not initialized in the constructor, meaning it could have an undefined value when the contract is first deployed. If last_block_number
is accessed before being set (e.g., in update_price
or update_profit_max_unlock_time
), it could lead to incorrect behavior, such as bypassing the assert self.last_block_number <= _block_number
check. This could allow outdated or invalid price updates to be processed, potentially leading to incorrect price data being returned by the oracle. While this issue is low-risk, it introduces unnecessary complexity and could lead to unexpected behavior in the protocol.
Manual Review
Initialize last_block_number
in the constructor to a default value (e.g., block.number
at deployment):
I believe low to be appropriate, although could hear arguments for informational. The next `_block_number` for each price/max unlock time update will always be greater than the default zero, so the assertion of `assert self.last_block_number <= _block_number, "Outdated"` will pass without issue, but for consistency could be updated during deployment. Arguably at deployment, an update that has been verified via the verifier has not occur yet, so there would likely be no issues here given after the first correct update it will work as intended. The first update for price/profit max unlock time will also unlikely be outdated based on block number, which can be presumed to be true given this are extracted and verified within the OOS `StateProofVerifier`.
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.