gdk-pixbuf/pixops/pixops.c | 22 17 + 5 - 0 !
1 file changed, 17 insertions(+), 5 deletions(-)

 pixops: be more careful about integer overflow

Our loader code is supposed to handle out-of-memory and overflow
situations gracefully, reporting errors instead of aborting. But
if you load an image at a specific size, we also execute our
scaling code, which was not careful enough about overflow in some
places.

This commit makes the scaling code silently return if it fails to
allocate filter tables. This is the best we can do, since
gdk_pixbuf_scale() is not taking a GError.

https://bugzilla.gnome.org/show_bug.cgi?id=752297

gdk-pixbuf/pixops/pixops.c | 6 5 + 1 - 0 !
1 file changed, 5 insertions(+), 1 deletion(-)

 [patch] pixops: fix oversight for cve-2015-4491

The n_x variable could be made large enough to overflow, too.

Also included are various testcases for this vulnerability:
- The original exploit (adapted for the testsuite)
- Causing overflow by making both X and Y variables large
- Causing overflow using only the X variable
- Causing overflow using only the Y variable

https://bugzilla.gnome.org/show_bug.cgi?id=752297

gdk-pixbuf/pixops/pixops.c | 75 55 + 20 - 0 !
1 file changed, 55 insertions(+), 20 deletions(-)

 [patch] pixops: fail make_weights functions on oom

The weights could grow very large under certain circumstances, in
particular in security-relevant conditions, including the testsuite.
By allowing the weight allocation to fail, this can be worked around.

https://bugzilla.gnome.org/show_bug.cgi?id=754387

gdk-pixbuf/io-tga.c | 124 82 + 42 - 0 !
1 file changed, 82 insertions(+), 42 deletions(-)

 [patch] tga: wrap tgacolormap struct in its own api

Instead of poking into it directly.

gdk-pixbuf/io-tga.c | 14 3 + 11 - 0 !
1 file changed, 3 insertions(+), 11 deletions(-)

 [patch] io-tga: colormaps are always present, so always parse them.

We might end up with a colormap with 0 entries, but whatever, it's a
colormap.

gdk-pixbuf/pixops/pixops.c | 10 5 + 5 - 0 !
1 file changed, 5 insertions(+), 5 deletions(-)

 [patch] pixops: don't overflow variables when shifting them

If we shift by 16 bits we need to be sure those 16 bits actually exist.
They do now.

gdk-pixbuf/pixops/pixops.c | 34 17 + 17 - 0 !
1 file changed, 17 insertions(+), 17 deletions(-)

 [patch] pixops: use gint64 in more places to avoid overflow when
 shifting

gdk-pixbuf/gdk-pixbuf-scale.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] avoid integer overflow in gdk_pixbuf_rotate_simple

Same as before: don't do ptr = base + y * rowstride if y and
rowstride are integers.

gdk-pixbuf/io-ico.c | 32 17 + 15 - 0 !
1 file changed, 17 insertions(+), 15 deletions(-)

 [patch] ico: protect against overflow

gdk-pixbuf/io-bmp.c | 9 9 + 0 - 0 !
1 file changed, 9 insertions(+)

 [patch] bmp: reject bogus depth

Erroring out early if we find a bogus image depth is
the right thing to do, and avoids possible memory
overruns later on.

https://bugzilla.gnome.org/show_bug.cgi?id=747605

gdk-pixbuf/io-bmp.c | 11 11 + 0 - 0 !
1 file changed, 11 insertions(+)

 [patch] bmp: reject impossible palette size

bmp headers contain separate fields for the number of colors,
and the bit depth. Catch the impossible n_colors > 1 << depth
and error early, before it causes a out-of-bounds memory
access when decoding the colormap.

https://bugzilla.gnome.org/show_bug.cgi?id=758991

gdk-pixbuf/io-jpeg.c | 26 22 + 4 - 0 !
1 file changed, 22 insertions(+), 4 deletions(-)

---

gdk-pixbuf/io-gif.c | 59 52 + 7 - 0 !
1 file changed, 52 insertions(+), 7 deletions(-)

---