This now prints an additional
> CONTEXT: unnamed portal parameter $1 = ''
on azure, presumably as a result of a version update or configuration
change. Strip this additional line from the error info, the same as
already done in one other place in the test.
Don't allow calling fclose() on the stream while in the user
filter callback. This is basically the same protection as xp_ssl
streams use during callback invocations.
There are more issues in this general area (e.g. stack overflow
on stream_filter_remove), but this addresses freeing the stream
during the filter callback invocation at least.
When making the relative path, we must not stop on a `:\` sequence in
the middle of the filename. This is only significant on Windows as it
may indicate an absolute filename, but this is already checked at the
beginning of the function.
Note that the bug and this patch affects all systems. However, on
Windows the file is no longer extracted at all, since Windows NTSF does
not allow filenames containing colons.
Closes GH-7528.
We address the `::setSize(0)` case by setting `array->element = NULL`
and `array->size = 0` before we destroy the elements.
Co-authored-by: Tyson Andre <tyson.andre@uwaterloo.ca>
Closes GH-7503.
It makes no sense to compare IPv6 address ranges as strings; there are
too many different representation possibilities. Instead, we change
`_php_filter_validate_ipv6()` so that it can calculate the IP address
as integer array. We do not rely on `inet_pton()` which may not be
available everywhere, at least IPv6 support may not, but rather parse
the IP address manually. Finally, we compare the integers.
Note that this patch does not fix what we consider as reserved and
private, respectively, but merely tries to keep what we had so far.
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
Closes GH-7476.
This has been reported as bug #78984, and is generally and properly
fixed as of timelib 2020.3 (PHP-8.0). However, it is not fixed in
PHP-7.4, where the test results in an OOB read, and an unterminated
C string when calling `::getName()`. Therefore, we apply a minimal
fix which just avoids this dangerous behavior.
We must never strip embedded whitespace; we only need to skip values
when that option is set, and make sure that we keep BC regarding the
different behavior for "cdata" and "complete" elements (for the former,
the whole element is skipped; for the latter only the "value" key).
We also fix erroneous `int` types which should actually be `size_t`.
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
Closes GH-7493.
offsetSet did not account for the fact that the array may no longer exist after
the field is overwritten. This fixes that.
Add test of resizing both to the empty array and a smaller array - there should
be no valgrind warnings with a proper fix.
Alternate approach to #7486 (described in https://bugs.php.net/bug.php?id=81429)
We need to allocate buffers for the file mapping names which are large
enough for all potential keys (`key_t` is defined as `int` on Windows).
Regarding the test: it's probably never a good idea to use hard-coded
keys (should always use `ftok()` instead), but to reliably reproduce
this Windows specific issue we need to, and it shouldn't be an issue on
that OS.
Closes GH-7448.
If buf_len is zero, this would leave behind a dangling pointer
to an already released header.str. Make sure this can't happen
by always overwriting the pointer.
Closes GH-7376.
The CURLOPT_DEBUGDATA will point to the old curl handle after
copying. Update it to point to the new handle.
We don't separately store whether CURLINFO_HEADER_OUT is enabled,
so I'm doing this unconditionally. It should be harmless if
CURLOPT_DEBUGFUNCTION is not used.
If we assemble a zend_string manually, we need to end it with a NUL
byte ourselves.
We also fix the size calculation for that zend_string; there is no need
for the extra byte for each part, and we don't have to multiply by two,
since we're using DnsQuery_A(), not DnsQuery_W () (in which case we
would have to do the character set conversion, anyway). This avoids
over-allocation, and the need to explicitly set the string length.
Finally, we use the proper access macro for zend_strings.
Closes GH-7427.
It is insufficient to check whether the `base` is contained in `fname`;
we also need to ensure that `fname` is properly separated. And of
course, `fname` has to start with `base`.
This is a non-intrusive, minimal fix for bug #81316, which prevents
a bailout during imap RSHUTDOWN and prevents the basic shutdown
handler from being skipped.
I wasn't able to make the issue reproduce in a small test.
The fix for bug #73151[1] cured the symptoms, but not the root cause,
namely xmlParse() must not be called recursively. Since that bugfix
also messed up the error handling, we basically revert it (but also
simplify the return), and then prevent calling the parser recursively.
[1] <https://github.com/php/php-src/pull/2166/commits/f2a8a8c068995a5d780882c556cedd53bce3827d>
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
Closes GH-7363.
The stream position is not related to the buffer, and needs to be
updated for non-seekable streams as well. The erroneous condition
around the position update is a relict of an old commit[1].
The unexpected test expectation is due to bug #81345.
[1] <https://github.com/php/php-src/commit/088e2692c3d1e680fd3d9306c4adb417e761acff>
Closes GH-7356.
When flushing the stream filters actually causes data to be written to
the stream, we need to update its position, because that is not done by
the streams' write methods.
Closes GH-7354.
The recent fix for bug 52093 is not compatible with LibreSSL ≥ 2.7.0,
which we recognize as mostly OpenSSL 1.1.0 compatible, but they still
do not support `ASN1_INTEGER_set_int64()`.
Closes GH-7339.
If `P->len` is negative (not only when it is `SQL_NULL_DATA`), we must
not go on, because the following code can't deal with that. This means
that the output parameter will be set to `NULL` without any indication
what went wrong, but it's still better than crashing.
Closes GH-7295.
Derick Rethans