Dria

Summary

We know that the whole system depends on the function finalityValidation. It is the one that issues the final ratings of requests to llm oracle, which will be used by buyer agents. .o if the finalize validation function does not work for any reason - it will violate the Buyer Agent functionality, which in turn violates the Swan functionality.

Now consider finalizeValidation.

For each generation of the response to the request, the validator gives its own ratings. According to the valuators in fineValidation, stddev is considered.
Stddev in turn calls the average function, which sums all the estimates in the array.
This sum is not unchecked - accordingly can easily overflow if one of the evaluations is intentionally set as uint256.max

The ratings come from the validate function, which does not have any control over the range of ratings from validators.

Nothing prevents validators to give uint256.max score

This will cause a DoS function fineValidation for the given taskId due to overflow, which in turn violates the flow protocol

Vulnerability Details

In fact, any validator can vote for any generation (only if he has not generated the response to this request himself)

To become a validator you have to make a deposit (which can be returned later) in LLMOracleRegistry function. .The attack can be carried out even completely free of charge, just in one transaction we
1.Register as a validator
2. Issues all ratings = uint256.max for each generation in the taskId that we want DoS
3. unregister as validator and withdraw money back

Impact

Severity: High - Any user can DoS protocol behaviour for free for 99,99% tasks (Only tasks with 0 numValidation parameter cant be DoS by this way)

Tools Used

Manual Review

Recommendations

Add range for validator scores. For example [1, 100], or if you want to save current score ranges, you can see this note about average calculation without overflow