zend_save_lexical_state() can be nested multiple times, for example for
the parser initialization and then in the heredoc lexing. The input
should not be freed if we restore to the same filtered string.
Closes GH-16716.
This fixes issues causing buffer over-read that leak heap content:
- RESP packet field default left over for COM_LIST
- RESP packet upsert filename
- OK packet message
- RESP packet for stmt row data
- ps_fetch_from_1_to_8_bytes
- ps_fetch_float
- ps_fetch_double
- ps_fetch_time
- ps_fetch_date
- ps_fetch_datetime
- ps_fetch_string
- ps_fetch_bit
- RESP packet for query row data (just possible overflow on 32bit)
It also adds various protocol tests using a new fake server.
When the current data is invalid, NULL must be returned. At least that's
how the check in SPL works and how other extensions do this as well.
If we don't do this, an UNDEF value gets propagated to a return value
(misprinted as null); leading to issues.
Closes GH-16825.
zend_is_callable_ex() can unfortunately emit a deprecation, and then
a user error handler can throw an exception. This causes an assert
failure at ZEND_VM_NEXT_OPCODE(). We fix this by checking if there's an
exception after zend_is_callable_ex().
Closes GH-16803.
FreeBSD 13.2 is no longer supported[1], and apparently the respective
Cirrus CI image has been removed. We update to FreeBSD 13.3.
This also requires to disable some compiler warnings now, and adapt a
test case.
[1] <https://www.freebsd.org/security/#sup>
[2] <https://github.com/php/php-src/runs/33044888209>
Co-authored-by: David Carlier <devnexen@gmail.com>
Closes GH-16817.
PHP-8.1 is not ready for ICU >= 75.1 which requires C++17 support.
Thus we force the usage of icu4c@74, what is scheduled for removal in
May 2025, though.
Closes GH-16789.
When returning an UNDEF value, it actually becomes NULL.
The following code took this into account:
28344e0445/ext/opcache/jit/zend_jit_trace.c (L2196-L2199)
But the stack does not update the type to NULL, causing a mismatch.
Closes GH-16784.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
This is only defined as of PHP-8.4; alternatively we could also inline
the `brew --prefix` call, but that makes it harder for upward merges.
Closes GH-16785.
cURL 8.11.0 added a couple of packages to `Requires.private`, but these
packages are irrelevant when building against a shared libcurl. For
some reason, these private requirements are checked when we're doing
`pkg-config --cflags` (that happens with the preinstalled pkg-config
0.29.2, as well as with pkgconf 2.3.0). To avoid further messing with
these packages, we just drop the `Requires.private` line from
libcurl.pc.
See GH-16741 for more details.
Closes GH-16783.
Reproducer: https://github.com/php/php-src/issues/16727#issuecomment-2466256317
The root cause is a data race between two different threads:
1) We allocate a lower cased name for an anonymous class here:
f97353f228/Zend/zend_compile.c (L8109)
2) This gets looked up as an interned string here:
f97353f228/Zend/zend_compile.c (L8112)
Assuming that there are uppercase symbols in the string and therefore
`lcname != name` and that `lcname` is not yet in the interned string table,
the pointer value of `lcname` won't change.
3) Here we add the string into the interned string table:
f97353f228/Zend/zend_compile.c (L8223)
However, in the meantime another thread could've added the string into the interned string table.
This means that the following code will run, indirectly called via the `LITERAL_STR` macro,
freeing `lcname`: 62e53e6f49/ext/opcache/ZendAccelerator.c (L572-L575)
4) In the reproducer we then access the freed `lcname` string here:
f97353f228/Zend/zend_compile.c (L8229)
This is solved in my patch by retrieving the interned string pointer
and putting it in `lcname`.
Closes GH-16748.
There are two issues:
1) There's an off-by-one in the check for the minimum file size for a
tar (i.e. `>` instead of `>=`).
2) The loop in the tar parsing parses a header, and then unconditionally
reads the next one. However, that doesn't necessarily exist.
Instead, we remove the loop condition and check for the end of the
file before reading the next header. Note that we can't use
php_stream_eof as the flag may not be set yet when we're already at
the end.
Closes GH-16700.
Adding two exit early safeguards in the *nix configuration build script:
1) Given the initial cd into the build tree fails (the project root),
the `buildconf` script exits with non-zero status (failure).
2) Given the grep command does not exist or `configure.ac` AC_INIT [1]
expectations are unmet, the buildconf script exits non-zero.
Additionally quoting the pathname to cd into and the empty CD_PATH
parameter for portability, also for systems that are using a
non-portable pathname [2] for the build tree.
The initial CD safeguard has been applied to the `buildconf` and
four more scripts:
- build/genif.sh
- scripts/dev/credits
- scripts/dev/genfiles
- scripts/dev/makedist
Rationale:
Cd-ing into the project root should always prematurely exit w/ FAILURE
as a required precondition for its invocation has not been met. This
should never go unnoticed as it always requires user intervention.
Similar and more specifically to the PHP build on *nix systems, the
grep command is required early to obtain the `php_extra_version` from
configure.ac. Previously, if the grep command is missing (or failing
due to not matching the line with the AC_INIT macro [1]), the internal
dev parameter would always be zero (0) which can easily result in the
situation that the configure script is not being rebuilt. This is
cumbersome as the rebuild of a configure script is more likely required
with checked-out dev versions under change rather than an already
properly set-up build environment on a dedicated build or release
system. Missing the fact that either the grep utility is missing or
the expectation of having the AC_INIT macro in configure.ac is unmet
should never go unnoticed as it always requires user intervention.
[1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Initializing-configure.html
[2]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271
Closes GH-16717.
When passing an array, the key entry can get converted to a string if it
is an object, but this actually modifies the original array entry.
The test originally outputted:
```
array(2) {
[0]=>
string(...) => ...
[1]=>
string(0) ""
}
```
This is unexpected. Use zval_try_get_string() to prevent this behaviour.
Closes GH-16693.
For rename_variation12.phpt this is actually not necessary, since there
is no rename_variation11.phpt, but we still fix it to be in sync with
rename_variation12-win32.phpt which actually is prone to parallel
conflicts.
(cherry picked from commit d4263ddc40)