Since #737 gdImageColorTransparent does not correctly handle the case that im->transparent = -1
(which is the initial value and used to indicate no transparent colour has been set).
This leads to undefined behaviour via an out-of-bound write:
im->alpha[im->transparent] = gdAlphaOpaque;
(in practice I assume this merely overwrites an earlier struct member)
This can be triggered via loading a gif through gdImageCreateFromGifPtr
third_party/gd/source/gd.c:922:2: runtime error: index -1 out of bounds for type 'int [256]'
#0 0x5629c034a839 in gdImageColorTransparent third_party/gd/source/gd.c:922:29
#1 0x5629c034ebf0 in gdImageCreateFromGifCtx third_party/gd/source/gd_gif_in.c:328:4
#2 0x5629c034f14f in gdImageCreateFromGifPtr third_party/gd/source/gd_gif_in.c:186:7
Fixes#784.
There are small typos in:
- examples/copyrotated.c
- src/gd.c
- src/gd.h
- src/gd_avif.c
- src/gd_nnquant.c
- src/gd_tga.c
- src/gd_topal.c
- src/wbmp.c
- tests/avif/compare_avif_to_png.c
Fixes:
- Should read `requires` rather than `reqiures`.
- Should read `of the` rather than `ofthe`.
- Should read `memory` rather than `memmory`.
- Should read `maximum` rather than `maxmum`.
- Should read `intersection` rather than `intertersection`.
- Should read `hypotenuse` rather than `hypothenus`.
- Should read `flexibility` rather than `flexibilty`.
- Should read `always` rather than `alwasy`.
- Should read `also` rather than `alos`.
The fix for PHP bug 43828[1] changed the algorithm from drawing filled
pies from drawing multiple triangles to drawing a single polygon. Due
to quirks of the filled polygon drawing algorithm, we had to filter out
extraneous vertices. This lead, however, to a bug regarding displaced
starting and ending points near 90° and 270° degrees, which we fix by
reinserting these vertices if they had been removed.
[1] <https://bugs.php.net/bug.php?id=43828>
Git ident attributes were in most cases utilized with SVN and keywords
substitutions, where $Id$ were replaced with certain revision from the
repository. In Git this functionality is different. Each $Id$ needs to
be defined in .gitattributes file to be effective. This patch removes
unused and outdated attributes.
gdImageCreate() doesn't check for oversized images and as such is prone
to DoS vulnerabilities. We fix that by applying the same overflow check
that is already in place for gdImageCreateTrueColor().
CVE-2016-9317
We remove the special casing for "point" rectangles with thick!=1 altogether,
and restrict the special casing for "line" rectangles to thick==1. We move
this necessary special casing (it fixes issue #172) towards the bottom of the
function like it is in PHP's bundled libgd.
This makes the code better readable in the sources, and we get syntax
highlighting in the generated HTML wherever we want it (i.e. not necessarily
always as with `-hl all`).
Otherwise we get artifacts regarding transparency. That happens with the
current implementation of gdImageFilledArc() unless gdChord or gdNoFill
are set. When gdPie is set, however, the filled arc is drawn in wedges,
which are polygons of three points, and so some overlap is natural.
To resolve the issue, we stick with the current algorithm of calculating the
wedges, but instead of drawing each polygon separately, we put the *relevant*
points in a large array, and draw a single polygon. That also is supposed to
improve the performance considerably.
Note that this modification will change the results when gdImageSetStyle()
or gdImageSetBrush() are used, but we believe that this modification is
also an improvement in this regard, even though it still might not make much
sense to use these functions with gdImageFilledArc().
Currently gd_error() forwards to gd_error_ex(). However, both functions
accept a variable number of arguments, and simply forwarding the va_list
isn't portable, see <http://c-faq.com/varargs/handoff.html>. This article
also describes the usual workaround, namely to let the second function
accept a va_list instead of variable number of arguments.
We do so by introducing a static helper, what does not affect API/ABI
compatibility.
As reported in <https://bugs.php.net/64641> 1-dimensional horizontal
filled polygons are not drawn at all. That is caused by the scanline
algorithm used for drawing filled polygons which skips the drawing of
horizontal edges, because that is normally not necessary. If, however,
the polygon consists of horizontal edges only, that obviously doesn't
work, so we add a special case handling.
(cherry picked from commit f9f10fa9d4)
As reported in <https://bugs.php.net/64641> 1-dimensional horizontal
filled polygons are not drawn at all. That is caused by the scanline
algorithm used for drawing filled polygons which skips the drawing of
horizontal edges, because that is normally not necessary. If, however,
the polygon consists of horizontal edges only, that obviously doesn't
work, so we add a special case handling.
Thick lines are drawn by gdImageFilledRectangle(), which iterates over
the x ordinate first (Z order) to apply the style pattern. While this works
fine for vertical and diagonal lines, it obviously fails for horizontal
lines, which have to be iterated over in N order.
To fix this bug, we introduce the helpers gdImageFilled(H|V)Rectangle(),
which may be reused for other purposes as well.
Pierre Joye
Robert Hart
Tim Gates
Michael Voříšek
Mike Frysinger
Christoph M. Becker
wilson chen
Fábio Cabral Pacheco
Peter Kokot