This testing code was never meant to be used this way, but fixing this
will at least stop fuzzers from complaining about this, so might still
be worthwhile.
Closes GH-16919.
There doesn't seem to be a thread post-startup hook that runs after
zend_startup_cb() that could be used for this
this fix is similar to accel_startup_ok() as seen here: fc1db70f10/ext/opcache/ZendAccelerator.c (L2631-L2634)
Closes GH-16853.
While the test obviously succeeds on Windows, it may occasionally
conflict with file_put_contents_variation7-win32.phpt[1], so we skip it
like we do for many other of these tests which have win32 pendants.
[1] <https://github.com/php/php-src/actions/runs/11527743659/job/32093951818>
Closes GH-16722.
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.
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.
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>
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.
