Fix UAF/Iterator Invalidation issue in optimization context.#4193
Merged
copybara-service[bot] merged 1 commit intomainfrom May 4, 2026
Merged
Fix UAF/Iterator Invalidation issue in optimization context.#4193copybara-service[bot] merged 1 commit intomainfrom
copybara-service[bot] merged 1 commit intomainfrom
Conversation
copybara-service
Bot
force-pushed
the
test_908984112
branch
from
52f0351 to
b5a8c2b
Compare
The OptimizationContext contains (among other things) a map from FunctionBase* to the topo sort of that function. This topo sort is stored in a list that is made to delete itself if the function is changed using a ChangeListener. If one of the functionBases with this topo sort list is deleted the OptimizationContext was not notified so both a dangling pointer to the function and a (now detached) change listener was kept around. This could lead to use after free and iterator invalidation issues. First there is the obvious risk that if a pointer is reissued by the allocator map index operations could incorrectly return data for the old function. More likely however if a new FunctionBase is created the resize of the map will cause UAF when we try to add the copied listeners onto the deleted function (and again when we try to delete the moved-away listeners for that matter). This needs to be solved by having the change-listener inform the OptimizationContext that it needs to be deleted and not calling UnregisterChangeListener in this case because the function it's attached to is currently iterating over the list of change-listeners so modifying it could invalidate iterators. PiperOrigin-RevId: 910157057
copybara-service
Bot
force-pushed
the
test_908984112
branch
from
b5a8c2b to
ae934e2
Compare
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.
Fix UAF/Iterator Invalidation issue in optimization context.
The OptimizationContext contains (among other things) a map from FunctionBase* to the topo sort of that function. This topo sort is stored in a list that is made to delete itself if the function is changed using a ChangeListener.
If one of the functionBases with this topo sort list is deleted the OptimizationContext was not notified so both a dangling pointer to the function and a (now detached) change listener was kept around.
This could lead to use after free and iterator invalidation issues.
First there is the obvious risk that if a pointer is reissued by the allocator map index operations could incorrectly return data for the old function.
More likely however if a new FunctionBase is created the resize of the map will cause UAF when we try to add the copied listeners onto the deleted function (and again when we try to delete the moved-away listeners for that matter).
This needs to be solved by having the change-listener inform the OptimizationContext that it needs to be deleted and not calling UnregisterChangeListener in this case because the function it's attached to is currently iterating over the list of change-listeners so modifying it could invalidate iterators.