FinalizeValidation Function Lacks Timeout, Causing Task State Lock and Denial of Service

Summary

In the Swan protocol's LLM Oracle Manager, the respond function allows generators to submit their responses for a given task. However, if the task's status remains stuck in PendingValidation due to validators not responding, the system lacks a mechanism to progress the task or handle such scenarios. This can lead to generators having their responses locked, preventing further interactions, and ultimately blocking task completion and reward distribution.

Vulnerability Details

Function Under Scrutiny:

Issue Description:

• Stuck Task Status:

  • If TaskStatus remains in PendingValidation indefinitely, generators' responses remain locked.

  • Without validators responding, the task cannot progress to completion.

• Lack of Timeout/Fallback Mechanism:

  • The contract does not implement a timeout or alternative pathway to handle scenarios where validators fail to respond.

  • This absence means tasks can remain perpetually in an incomplete state.

Potential Exploit Scenario:

1. Task Submission:

   • A user submits a task with numValidations > 0, expecting validators to participate.

2. Generators Respond:

   • Generators submit their responses, locking their tokens or stakes.

3. Validators Fail to Respond:

   • Validators do not respond due to inactivity, malicious intent, or other issues.

4. Task Remains Stuck:

   • Without validator responses, the task status does not update, preventing reward distribution and further interactions.

Impact

Severity: High

Potential Consequences:

1. Permanent Locking of Funds:

   • Generators' stakes or rewards remain locked, preventing them from withdrawing or participating in future tasks.

2. Service Disruption:

   • Essential protocol functions related to task completion and reward distribution are blocked, affecting overall system functionality.

3. Economic Loss:

   • Users and oracles may suffer financial losses due to inability to complete tasks and receive rewards.

4. Erosion of Trust:

   • Persistent issues can diminish user and oracle trust in the protocol's reliability and fairness.

Recommendation

Implement a Timeout and Fallback Mechanism

• Description:

  • Introduce a timeout feature that automatically progresses the task status if validators do not respond within a specified timeframe.

  • Provide alternative pathways, such as allowing users to reassign or cancel tasks after the timeout.

• Implementation Example:

  uint256 public constant VALIDATION_TIMEOUT = 7 days;

  ​

  struct Task {

  TaskStatus status;

  uint256 creationTime;

  // ... other fields ...

  }

  ​

  function respond(uint256 taskId, uint256 nonce, bytes calldata output, bytes calldata metadata)

  public

  onlyRegistered(LLMOracleKind.Generator)

  onlyAtStatus(taskId, TaskStatus.PendingGeneration)

  {

  // ... existing logic ...

  ​

  if (task.parameters.numValidations == 0) {

  _increaseAllowance(msg.sender, task.generatorFee);

  }

  ​

  // Update task status or handle post-response logic

  }

  ​

  function finalizeTask(uint256 taskId) public {

  Task storage task = tasks[taskId];

  require(task.status == TaskStatus.PendingValidation, "Task not pending validation");

  require(block.timestamp >= task.creationTime + VALIDATION_TIMEOUT, "Validation period not yet over");

  ​

  // Handle task finalization, rewards distribution, etc.

  task.status = TaskStatus.Completed;

  // ... additional logic ...

  }

  ​

• Benefits:

  • Prevents Permanent Locking: Ensures tasks do not remain stuck indefinitely, allowing for eventual completion or reassignment.

  • Enhances User Experience: Provides clarity and resolution for tasks that encounter validation delays.

  • Maintains Protocol Integrity: Keeps the system functional and reliable, maintaining trust among users and oracles