Setting the stream context via php_stream_context_to_zval() will
increase the reference count. So if the new context is created, then it
will end up with a reference count of 2 while it should be 1.
Credits to cmb for the analysis. I arrived at the same patch as he did.
Closes GH-12523.
When we have two processes both trying to cache a WSDL, they might start
writing the data to the same temporary file, causing file corruption due
to the race condition. Fix this by creating a temporary file first, and
then moving it to the final location. If moving fails then we know
another process finished caching first.
This also fixes#67617 as a consequence of its implementation.
Closes GH-12469.
This always results in a segfault when trying to instantiate, so this never
worked. At least throw an error instead of segfaulting to prevent developers
from being confused.
Closes GH-12420.
There are two issues:
- UAF because the hashmap resized while being iterated over, yet the local
variables used internally in the macros are not updated.
- The hashmap being iterated over is modified: entries are deleted after
other entries have been added. This causes the deletion to fail sometimes
because indices of buckets have shifted.
Fix it by using a while loop iteration and HashPosition position tracker
instead.
Issue exists on PHP 8.1 too, but is much harder to trigger.
The test file reproduces the issue reliably on PHP 8.2 and up.
Closes GH-12409.
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).
PHP 8.1 introduced a seemingly unintentional BC break in ca94d55a19 by
blocking the (un)serialization of DOM objects.
This was done because the serialization never really worked and just
resulted in an empty object, which upon unserialization just resulted in
an object that you can't use.
Users can however implement their own serialization methods, but the
commit made that impossible as the ACC flag gets passed down to the
child class. An approach was tried in #10307 with a new ACC flag to
selectively allow serialization with subclasses if they implement the
right methods. However, that was found to be too ad hoc.
Instead, let's abuse how the __sleep and __wakeup methods work to throw
the exception instead. If the child class implements the __serialize /
__unserialize method, then the throwing methods won't be called.
Similarly, if the child class implements __sleep and __wakeup, then
they're overridden and it doesn't matter that they throw.
For the user, this PR has the exact same behaviour for (sub)classes that
don't implement the serialization methods: an exception will be thrown.
For code that previously implemented subclasses with these methods, this
approach will make that code work again. This approach should be both BC
preserving and unbreak user's code.
Closes GH-12388.
For the test:
Co-authored-by: wazelin <contact@sergeimikhailov.com>
After preloading has executed, the executor globals for class_table and
function_table are still referring to the values during preloading.
If no request happens after that then these values will remain dangling
pointers. If then the -v option on CLI or -h option (and possibly
others) on CGI is provided, there is a double free.
Fix it by nulling the pointers explicitly after preloading has finished
to fix it for all SAPIs.
Closes GH-12311.
Many methods in SimpleXML reset the iterator when called. This has the
consequence that mixing these operations with loops can cause infinite
loops, or the loss of iteration data.
Some people may however rely on the resetting behaviour. To prevent
unintended breaks in stable branches, let's only apply the fix to master.
This reverts GH-12193, GH-12229, GG-12247 for stable branches while
keeping them on master, adding a note in UPGRADING as well.
This test triggers narrowing for two ops: first ZEND_ADD_ARRAY_ELEMENT,
and then ZEND_ASSIGN.
The type inference happens in the following order:
1) The ZEND_ADD_ARRAY_ELEMENT infers type 0x40e04080 (packed flag is set),
arr_type=0 at this point because it hasn't been set by ZEND_INIT_ARRAY yet.
2) The ZEND_INIT_ARRAY infers type 0x40804080
3) The ZEND_ADD_ARRAY_ELEMENT infers type 0x40e04080, arr_type=0x40804080,
which does not have the packed flag set while the existing result of
ZEND_ADD_ARRAY_ELEMENT has the packed flag set.
This seems to occur because of the phi node introduced by the while
loop. If I remove the loop the problem goes away.
As Arnaud noted, this seems to be caused by a too wide type inference
for arr_type==0. We should keep the invariant that if x>=y then
key_type(x) >= key_type(y).
If we write the possible results down in a table we get:
```
arr_type resulting key type
--------------- --------------------------------------------------------------------------
HASH_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH
PACKED_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
HASH || PACKED -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
0 -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
```
As we can see, `HASH_ONLY > 0` but
`MAY_BE_ARRAY_NUMERIC_HASH < MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED`,
which violates the invariant.
Instead if we modify the zero case to have MAY_BE_ARRAY_NUMERIC_HASH instead,
we get the following table which satisfies the invariant.
```
arr_type resulting key type
--------------- --------------------------------------------------------------------------
HASH_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH
PACKED_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
HASH || PACKED -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
0 -> MAY_BE_ARRAY_NUMERIC_HASH
```
Broke in 1ffbb73.
Closes GH-10294.
