Reset inheritance_cache pointer of zend_class_entry upon serialization - #12401
Merged
dstogov merged 1 commit intoOct 11, 2023
Merged
Conversation
to opcache filecache. Usually, when a class is being loaded, a dependency tracking is performed after the call to zend_file_cache_script_store. But sometimes, when opcache cache is empty and there are many simultaneous outstanding requests for compilation, some classes do have their inheritance_cache initialized before the call to zend_file_cache_script_store, and in that case this pointer is serialized as-is. And when such a class is loaded from opcache filecache this pointer also loaded as-is, and now it points to some random location in memory. This causes segfaults occuring when traversing inheritance_cache of such classes. We need to reset inheritance_cache pointer of zend_class_entry upon serialization. This should have been done anyway since it is a sensible strategy to sanitize any memory pointer upon serialization (either by calling SERIALIZE_x macros or setting to NULL or any other deterministic value).
dstogov
added a commit
that referenced
this pull request
Oct 11, 2023
* PHP-8.1: Reset inheritance_cache pointer of zend_class_entry upon serialization (#12401)
dstogov
added a commit
that referenced
this pull request
Oct 11, 2023
* PHP-8.2: Reset inheritance_cache pointer of zend_class_entry upon serialization (#12401)
dstogov
added a commit
that referenced
this pull request
Oct 11, 2023
* PHP-8.3: Reset inheritance_cache pointer of zend_class_entry upon serialization (#12401)
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
2 participants
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.
to opcache filecache. Usually, when a class is being loaded, a dependency tracking is performed after the call to
zend_file_cache_script_store. But sometimes, when opcache cache is empty and there are many simultaneous outstanding requests for compilation, some classes do have theirinheritance_cacheinitialized before the call tozend_file_cache_script_store, and in that case this pointer is serialized as-is. And when such a class is loaded from opcache filecache this pointer also loaded as-is, and now it points to some random location in memory. This causes segfaults occuring when traversinginheritance_cacheof such classes (zend_accel_inheritance_cache_find).We need to reset
inheritance_cachepointer ofzend_class_entryupon serialization. This should have been done anyway since it is a sensible strategy to sanitize any memory pointer upon serialization (either by callingSERIALIZE_xmacros or setting toNULLor any other deterministic value).This fixes #8143 and possibly #11963.
A side note: it might be beneficial to reset
inheritance_cachepointer inzend_file_cache_unserialize_classtoo. It will enable to load incorrectly serialized classes (but from the other hand, if this patch goes in, it will be another PHP version with a new hashsum for filecache base directory).