This bug had already been fixed, but apparently there's no regression
test yet, so we add one.
Note that the expected image has black pixel artifacts, which are
another issue (perhaps bug #40158), and would have to be adressed
separately.
We must take into account the line padding, when we're reading XBM
files.
We deliberately ignore the potential integer overflow here, because
that would be caught by gdImageCreate() or even earlier if `bytes==0`,
what happens in libgd00094.phpt which we adapt accordingly.
GD2 stores the number of horizontal and vertical chunks as words (i.e. 2
byte unsigned). These values are multiplied and assigned to an int when
reading the image, what can cause integer overflows. We have to avoid
that, and also make sure that either chunk count is actually greater
than zero. If illegal chunk counts are detected, we bail out from
reading the image.
(cherry picked from commit 5b5d9db3988b829e0b121b74bb3947f01c2796a1)
We must not pretend that there are image data if there are none. Instead
we fail reading the image file gracefully.
(cherry picked from commit cdb648dc4115ce0722f3cc75e6a65115fc0e56ab)
* phpsec/PHP-7.0.13:
Fixed bug #73418 Integer Overflow in "_php_imap_mail" leads to crash
Fix#72696: imagefilltoborder stackoverflow on truecolor images
Fix#72482: Ilegal write/read access caused by gdImageAALine overflow
Fix bug #73144 and bug #73341 - remove extra dtor
remove unreferenced var came in with merge
Fix bug #73331 - do not try to serialize/unserialize objects wddx can not handle
fix version
set versions
We must not allow negative color values be passed to
gdImageFillToBorder(), because that can lead to infinite recursion
since the recursion termination condition will not necessarily be met.
(cherry picked from commit 863d37ea66)
Instead of rolling our own bounds check we use clip_1d() as it's done
in gdImageLine() and in external libgd. We must not pass the image
width and height, respectively, but rather the largest ordinate value
that is allowed to be accessed, i.e. width-1 and height-1,
respectively.
(cherry picked from commit 6499581af7)
We must not allow negative color values be passed to
gdImageFillToBorder(), because that can lead to infinite recursion
since the recursion termination condition will not necessarily be met.
Instead of rolling our own bounds check we use clip_1d() as it's done
in gdImageLine() and in external libgd. We must not pass the image
width and height, respectively, but rather the largest ordinate value
that is allowed to be accessed, i.e. width-1 and height-1,
respectively.
The color components are supposed to be in range 0..255, so we must not
cast them to `signed char`, what can be the default for `char`.
Port of <https://github.com/libgd/libgd/commit/77c8d359>.
The recently introduced test_image_equals_file() doesn't properly work for
palette images, because in this case only the palette indexes are compared,
what can lead to false positives and negatives as shown in the added test.
To fix that we convert palette images to truecolor, what is supposed to be
faster than calling imagecolorsforindex() for each pixel.
We furthermore rely on PHP's refcounting to free unused images; after all,
this is not C.
Firstly, there is no fundamental difference between running the tests on
freetype before and after 2.4.10, so we re-join the respective test cases.
Secondly, there are some minor differences in the results depending on
architecture, freetype versions and config options, so we cater to that
by allowing small deviations from the expectations.
