There's no need to actually try to trigger an out-of-memory condition
to proof the leak; instead we can simply rely on the Zend MM to report
the memory leaks in debug mode (at least on Linux). Therefore we
simplify the regression test, which also makes it run much faster.
* PHP-7.0:
Fixed bug #76459 windows linkinfo lacks openbasedir check
Add NEWS
Fixed bug #76459 windows linkinfo lacks openbasedir check
Fix bug #76557: heap-buffer-overflow (READ of size 48) while reading exif data
Fix bug #76423 - Int Overflow lead to Heap OverFlow in exif_thumbnail_extract of exif.c
Due to incorrect string termination and length handling, several HTML
entities missed the trailing semicolon.
We also fix the obviously wrong expectations in two already existing
tests.
The search path needs to be appended with the wild card. Till now, an
edge case existed, so then if a path is 259 bytes long, which is smaller
_MAX_PATH, the suffix would cause the final search path to become longer
than _MAX_PATH. It is an edge case, when the starting path happens to
have a specific length. If the starting path was longer than _MAX_PATH
or the addition of "\\*" would not exceed _MAX_PATH, the function was
correct. Except for rewind, which was broken in the case of the long
path.
Validate that "C" serialization payload is followed by "}" prior to
calling the unserialize() handler. This mitigates issues caused by
unserialize() not correctly handling strings that are not NUL
terminated. Making sure that there is a "}" at the end avoids the
problem.
Some JFIF images contain empty APP segments, i.e. those which consist
only of the marker bytes and the length, but without actual content.
It appears to be doubtful to have empty APP segments, but we should
apply the robustness principle, and accept these, instead of simply
failing in this case.
We choose to add empty APP segments to $imageinfo with an empty string
as value, instead of NULL, or even to omit these segments altogether.
This patch also fixes the potential issue that php_stream_read() might
not read the supposed number of bytes, which could result in garbage to
be added to the read value.
This reverts commit 94e9d0a2ae.
This code needs to be mindful about modifications to the array
happening during callback execution. It was written in a way that
only accessed the reference, which is guaranteed not to move. The
changed implementation instead accesses the array slot, leading to
use-after-free.
Run ext/standard/tests/array/bug61967.phpt under valgrind to see
the issue.
* all arguments for ftp_pasv are required
* $varname for getenv function isn't required anymore
* fsockopen and pfsockopen only require $hostname
* strtok can work with only one parameter
* strpbrk needs two parameters to work
* required parameters and add some parameters in openssl_* functions
The sizeof()s for Content-Length and Transfer-Encoding were missing
the trailing ":". Apart from being generally wrong, this no longer
verified that the header actually contains a colon, leading to the
null http_header_value being used.
Additionally, in the interest of being defensive, also make sure
that http_header_value is non-null by setting it to the end of
the header line (effectively an empty string) if there is no colon.
If the following conditions are correct, this value is not going
to be used though.
