Fix use-after-free in CollisionEnvFCL when a moved world object is copy-on-write cloned - #3797
Open
ohrad-robotics wants to merge 1 commit into
Open
Conversation
…py-on-write cloned World::ensureUnique() copy-on-write clones a World::Object when it is mutated while an external shared_ptr to it is still alive (e.g. RViz's MotionPlanningDisplay briefly holding a reference while it live-checks collisions for the goal/start state). CollisionEnvFCL::notifyObjectChange()'s MOVE_SHAPE fast path (moveit#3601) updated the cached FCL collision object's transform in place but never refreshed CollisionGeometryData::ptr.obj, a raw non-owning pointer into the World::Object. Once the pre-move object was destroyed, that pointer was left dangling, and the next collision check reading the object's id through it (CollisionGeometryData::getID()) was a use-after-free - reproducibly crashing RViz. Refresh the cached pointer via the existing FCLGeometry::updateCollisionGeometryData() helper, the same mechanism createCollisionGeometry() already uses for this exact copy-on-write scenario, before applying the transform update. Adds a regression test that forces the copy-on-write path and checks the cached World::Object pointer stays in sync via direct pointer comparison, so it fails deterministically without the fix rather than relying on the process actually crashing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was experiencing some rviz crashes while playing around with the moveit_resources_panda_moveit_config demo. I decided to throw Claude at it and uncovered a use-after-free bug in moveit_core. Rviz would crash if I introduced a simple box collision object, moved it so that it was in collision with the manipulator arm, and then tried to move the arm using the .
World::ensureUnique() copy-on-write clones a World::Object when it is mutated while an external shared_ptr to it is still alive (e.g. RViz's MotionPlanningDisplay briefly holding a reference while it live-checks collisions for the goal/start state). CollisionEnvFCL::notifyObjectChange()'s MOVE_SHAPE fast path (#3601) updated the cached FCL collision object's transform in place but never refreshed CollisionGeometryData::ptr.obj, a raw non-owning pointer into the World::Object. Once the pre-move object was destroyed, that pointer was left dangling, and the next collision check reading the object's id through it (CollisionGeometryData::getID()) was a use-after-free - reproducibly crashing RViz.
This PR:
Description
Please explain the changes you made, including a reference to the related issue if applicable
Checklist