Denial of Service in RACER Tested via FastExplorationFSM

Executive Summary

CVE-2026-71646 is a Denial of Service (DoS) vulnerability in the RACER software. It occurs in the FastExplorationFSM::optTimerCallback() function due to a cooldown bypass in repeated pair-opt attempts. Failed pair-opt attempts bypass the intended attempt cooldown and are retried at timer frequency. The cooldown mechanism uses recent_attempt_time_ and attempt_interval_ to prevent repeated optimization attempts within a short time interval. However, when a pair-opt attempt determines that the reallocated assignment has a higher cost, the callback may return immediately before updating recent_attempt_time_, allowing the failed attempt to bypass the cooldown.

Useful 0 Not Useful 0

Detection Guidance

Monitor CPU usage spikes and repeated error logs from the RACER software, particularly during exploration tasks. Check for excessive optTimerCallback() invocations in the swarm_exploration/exploration_manager/src/fast_exploration_fsm.cpp file. Look for repeated failed pair-opt attempts bypassing the cooldown mechanism.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause excessive CPU consumption, repeated error logging, unnecessary task-reallocation processing, and interference with normal exploration-state-machine execution. If exploited, it may lead to system slowdowns, degraded performance, or mission failure in robotics applications using RACER software.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability causes excessive CPU consumption and repeated error logging, which could interfere with normal system operations. While not directly tied to GDPR or HIPAA, such disruptions may impact data processing integrity and availability, potentially affecting compliance with requirements for secure and reliable system operation.

Useful 0 Not Useful 0

Mitigation Strategies

Update the cooldown timestamp recent_attempt_time_ at the start of every pair-opt attempt, including rejected ones. Implement a backoff mechanism for repeated failures and consider adding a separate timestamp recent_success_time_ for successful reallocations to prevent excessive retries.

Useful 0 Not Useful 0