Package: gdk-pixbuf / 2.31.1-2+deb8u7

Metadata

Package Version Patches format
gdk-pixbuf 2.31.1-2+deb8u7 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
CVE 2015 4491.patch | (download)

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

CVE 2015 4491 2.patch | (download)

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

CVE 2015 7673/0001 pixops Fail make_weights functions on OOM.patch | (download)

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

CVE 2015 7673/0002 tga Wrap TGAColormap struct in its own API.patch | (download)

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.

CVE 2015 7673/0003 io tga Colormaps are always present so always parse .patch | (download)

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.

CVE 2015 7674/0001 pixops Don t overflow variables when shifting them.patch | (download)

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.

CVE 2015 8875/0001 pixops use gint64 in more places to avoid overflow w.patch | (download)

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


CVE 2015 7552/0001 Avoid integer overflow in gdk_pixbuf_rotate_simple.patch | (download)

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.

0001 ico Protect against overflow.patch | (download)

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

 [patch] ico: protect against overflow


0001 bmp Reject bogus depth.patch | (download)

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

0001 bmp Reject impossible palette size.patch | (download)

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

CVE 2017 2862.patch | (download)

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

---
CVE 2017 1000422.patch | (download)

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

---