DeFiLayer 1Layer 2
14,723 OP
View results
Submission Details
Severity: low
Valid

Uninitialized `last_block_number` Variable

Description

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.

Affected Code

https://github.com/CodeHawks-Contests/2025-03-curve/blob/198820f0c30d5080f75073243677ff716429dbfd/contracts/scrvusd/oracles/ScrvusdOracleV2.vy#L61-L64

# @audit this variable is not initialized
last_block_number: public(uint256) # Warning: used both for price parameters and unlock_time
# smoothening

Vulnerability Details

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.

Tools Used

Manual Review

Recommended Mitigation Steps

Initialize last_block_number in the constructor to a default value (e.g., block.number at deployment):

self.last_block_number = block.number
Updates

Lead Judging Commences

0xnevi Lead Judge 3 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-block-number-not-initialized

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`.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.