Skip to content

Possible out-of-gas errors in HashConsensus.sol::_submitReport() due to unbounded _reportVariantsLength #1379

@dgusakov

Description

@dgusakov

Description

HashConsensus.sol supports different report hash variants. Oracle members can submit multiple variants for the same refSlot. All report variants are recorded on-chain in the _reportVariants mapping and every new variant increments _reportVariantsLength. When the report should be finalized, HashConsensus.sol iterates over all of the submitted report variants to determine the one with sufficient support (support >= quorum).

The issue lies in the ability to submit an unlimited number of report variants for the same refSlot. If one or more Oracle members submit a significant number of report variants, _submitReport() and _getConsensusReport functions might revert with Out of Gas errors while iterating over all report variants, effectively blocking report finalization until the next refSlot is reached.

_submitReport():

	while (
		varIndex < variantsLength &&
		_reportVariants[varIndex].hash != report
	) {
		++varIndex;
	}

_getConsensusReport():

	for (uint256 i = 0; i < variantsLength; ++i) {
		uint256 iSupport = _reportVariants[i].support;
		if (iSupport >= quorum) {
			variantIndex = int256(i);
			report = _reportVariants[i].hash;
			support = iSupport;
			break;
		}
	}

While the most obvious scenario for the issue to be exploited is the malicious actions of one of the Oracle members, malfunctioning Oracle software can also result in a significant number of report variants being submitted.

According to the estimations, around 7,000 report variants are required to block report processing with the post-Fusaka TX gas limit of 16.8M. Hence, the issue is unlikely under normal mainnet conditions. Nevertheless, it is worth fixing in one of the upcoming protocol releases.

Proposed fix

To fix the issue, the number of report variants each Oracle member can submit is proposed to be limited. The number of variants submitted by the Oracle member should be reset as soon as the first report for the new refSlot is submitted.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions