This regressed in cd53ce838a.
The loop with `zend_hash_iterators_update` hangs forever because
`iter_pos` can't advance to idx. This is because the
`zend_hash_iterators_lower_pos` upper bound is `target->nNumUsed`,
but that is set to `source->nNumOfElements`.
That means that if there are holes in the array, we still loop over all
the buckets but the number of bucket slots will not match.
Fix it by changing the assignment.
Closes GH-12831.
If there are two users that can execute the script that caches a WSDL,
but the script is owned by a single user, then the caching code will
name the cached file with the file owner username and a hash of the uri.
When one of the two tries to rename the file created by the other
process, this does not work because it has no permission to do so.
This then leaves temporary files floating in the temp directory.
To fix the immediate problem, unlink the file after rename has failed.
On the long term, this has to be fixed by taking the username of the
process instead of the username of the file owner.
Closes GH-12841.
This is some additional info that might help to future RM's - those are the bits that are stumbled and felt they need to be clarified when releasing PHP-8.3.0
* Remove unused upper case tag static data
* Shrink size of static binary search tree
This also makes it more efficient on the data cache.
* Update patches
* Avoid passing NULL to xmlSwitchToEncoding
This otherwise switches to UTF-8 on libxml2 2.12.0
* Split tests for different error reporting behaviour in libxml2 2.12.0
* Avoid deprecation warnings for libxml2 2.12.0
We can't fully get rid of the parser globals as there are still APIs
that implicitly use them.
* Temporarily disable part of test for libxml 2.12.0 regression
See https://gitlab.gnome.org/GNOME/libxml2/-/issues/634
* Review fixes
* [ci skip] Update test description
The former implementation of huge pages for PHP code segments may
fail to map in certain scenarios. For instance, if the initial
'r-x-' segment is not PHP, it will result in a failure to map into
huge pages. Consequently, the optimization for huge pages with PHP
code will no longer be effective.
This patch improves the implementation by accurately matching all
'r-x-' segments until it locates the PHP code segment. Subsequently,
it performs the necessary huge page mapping.
Reviewed-by: chen-hu-97 <hu1.chen@intel.com>
Signed-off-by: PeterYang12 <yuhan.yang@intel.com>
This is _not_ exploitable right now because libxml guarantees right now
a maximum string length of 1M bytes. But if that limit were to ever
change this could overflow in the future leading to exploits.
Again, not exploitable right now, but just making it more future-proof.
* Fast path for when there is nothing to trim in mb_trim
* Make mb_trim decide between linear search vs hash table lookup
Using empirical experiments I noticed that on my i7-4790 the hash table
approach becomes faster once we have more than 4 code points in the trim
characters, when evaluated on the worst case.
This patch changes the logic so that a hash table is used for a large
number of trim characters, and linear search when the number of trim
characters is <= 4.
