{"uuid": "81e8e904-b4c9-4602-86c9-fabf2d1eab42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71641", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/91656fd120c49a779992aba62c1d58af", "content": "# CVE-2026-71641\n\n[CVE ID]\n\nCVE-2026-71641\n\n\n[PRODUCT]\n\nEGO-Planner-v2\n\n\n[VERSION]\n\nEGO-Planner-v2 commit 5c99a95880401e2599638d567abc0e240396cb42.\n\n\n[PROBLEM TYPE]\n\nDenial of Service (DoS) caused by stale non-zero velocity state during emergency recovery.\n\n\n[DESCRIPTION]\n\nEGO-Planner-v2 contains an issue caused by the interaction between `traj_server`, `poscmd_2_odom`, and the `EGOReplanFSM` emergency recovery logic.\n\nWhile a local trajectory is active, `traj_server` publishes `PositionCommand` messages containing position, velocity, acceleration, and jerk. However, once the trajectory reaches its duration, command publication stops and no final hover or zero-velocity command is sent.\n\n`poscmd_2_odom` stores and continues reusing the last received `PositionCommand`. If the final stored command contains a non-zero velocity, the generated odometry may continue reporting that non-zero velocity even after the trajectory has ended and the position has stopped changing.\n\nWhen the FSM is in `EMERGENCY_STOP` with `flag_escape_emergency_ == false`, recovery requires `odom_vel_.norm() < 0.1` before transitioning to `GEN_NEW_TRAJ`. Because the stale non-zero velocity remains latched, this condition may never become true, leaving the FSM permanently stuck in `EMERGENCY_STOP`.\n\n\n[IMPACT]\n\nAn affected UAV may become unable to exit `EMERGENCY_STOP` after the active trajectory has finished.\n\nThis prevents the planner from resuming trajectory generation and can leave the UAV permanently unavailable for the remainder of the mission. In multi-UAV scenarios, one or more affected vehicles may stop participating in the coordinated task, resulting in denial of service, mission incompletion, or loss of swarm availability.\n\nThe reported odometry can also become internally inconsistent, with the position remaining stationary while the velocity remains non-zero.\n\n\n[ROOT CAUSE]\n\nThe issue is caused by inconsistent handling of trajectory completion and stale command data across multiple components.\n\nFirst, `traj_server` only publishes commands while `t_cur < traj_duration_`. After the trajectory expires, there is no unconditional branch that continues publishing the final trajectory position together with zero velocity, acceleration, and jerk.\n\nSecond, `poscmd_2_odom` stores the most recent `PositionCommand` and does not apply a timeout or invalidate stale command data when new commands stop arriving. Therefore, the final non-zero velocity command may remain latched indefinitely.\n\nThird, `EGOReplanFSM` uses `odom_vel_.norm() < 0.1` as a required condition for leaving `EMERGENCY_STOP`. Because the odometry velocity can remain stale and non-zero, the recovery condition may never be satisfied.\n\nThe combination of missing end-of-trajectory zero-velocity publication, indefinite reuse of stale command data, and a velocity-dependent recovery condition creates a permanent emergency-recovery deadlock.", "creation_timestamp": "2026-09-08T07:35:49.969706Z"}