fix(rmw): check implementation_identifier before casting guard condition data#8
Merged
SandraK82 merged 1 commit intoJul 8, 2026
Conversation
Contributor
|
Danke dir, Rico — sauber analysiert und genau richtig lokalisiert. Der blinde Cast von Ein Hinweis für alle Mitleser: derselbe ungeschützte Cast steht ein zweites Mal in der Finalize-Schleife von |
SandraK82
added a commit
that referenced
this pull request
Jul 8, 2026
Follow-up to #8: the finalize loop of rmw_wait had the same unguarded cast of gc->data as the readiness loop. Because it also writes `*f = 0`, it would corrupt rcl's foreign memory (guard conditions rcl created without rmw_create_guard_condition), not just read it. Apply the same implementation_identifier check here.
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
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.
Summary
Bei der Verwendung von zerodds als RMW-Implementierung mit rclrs (der reinen Rust-ROS2-Client-Bibliothek) stürzt der Knoten sofort mit einem Segfault in
rmw_waitab.rclrs erstellt intern über rcl (
rcl_wait_set_init) Guard-Bedingungen für die Verwaltung seiner Executor- und Wait-Sets. Diese Guard-Bedingungen werden nicht überrmw_create_guard_conditionerstellt, was bedeutet, dass ihr data-Feld keinunsigned int *ist, wie es der C-Wrapper erwartet - es enthält stattdessen das, was rcl dort abgelegt hat.Wenn
rmw_waitdie Guard-Bedingungen durchläuft undgc->datainunsigned int *casted und dereferenziert, liest es nicht definierten Speicher und es kommt zu einem Segfault.Grundursache
rmw_create_guard_conditionsetztgc->datakorrekt auf ein im Heap zugewiesenesunsigned int *-Flag. Allerdings erstellt rcl intern zusätzliche Guard-Bedingungen (für das Aufwachen des Executors und die Verwaltung der Wait-Sets), diermw_create_guard_conditionvollständig umgehen. Diese Guard-Bedingungen landen im anrmw_waitübergebenen Wait-Set-Array, aber ihr data-Feld ist keinunsigned int *.Spec-Bezug
N/A - interner Bugfix im RMW-C-Wrapper, kein OMG-Spec-Verhalten betroffen.
Test-Coverage
Breaking Change?
Nein
Checklist
Comments
Lokale Umgebung
Überprüft durch Ausführen eines reinen Rust-ROS2-Knotens mit
rclrs 0.7.0auf ROS Humble. Vor der Korrektur stürzte der Knoten beim Start sofort ab (Segfault). Nach der Korrektur läuft der Knoten korrekt mit Subscribern und Publishern.Getestet mit: zerodds, aus dem Quellcode kompiliert (1.0.0-rc.4) über Nix/naersk,
rclrs 0.7.0, ROS Humble in einer nix-shell für x86_64.Test-Coverage
Ich nutze die crate in einer Nix Umgebung, daher habe ich mir nur die minimal notwendigsten Abhängigkeiten für rmw-zerodds-shim vorbereitet, so dass die tests nicht durchlaufen können. Weiterhin besteht die Änderung hier nur aus einer C Datei. Vermutlich irrelevant für die Tests
AI
Viele Ideen hier sind in Zusammenarbeit mit Claude entstanden, da ich insbesondere noch meine ROS2 Nix Umgebung anpassen musste.