Fix use-after-free in write_property when object is released #10179
Conversation
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
dstogov
approved these changes
Jan 30, 2023
This was referenced Feb 10, 2023
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.
Fixes GH-10169
This fix does some additional refcounting in
write_property(particularly before/afterzend_verify_property_type) to detect releasing the object. That's unfortunate because it's not really needed as usually one can't modify local variables of other stack frames. Globals are the exception to this rule.This fix throws an error when the object gets released. However, it's not completely obvious to me if this is the "correct" behavior. It sounds more intuitive to drop the assignment. However, that is non-trivial as
zend_std_write_propertymust return a pointer to somezvalwhich should contain the assigned value. But as the object is released we can't point into its properties as usual, and allocating azvalwould mean that the caller ofwrite_propertyneeds to release it.So, I wonder if this is something actually worth fixing...