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

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.

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.

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.

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)

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.

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

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.

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

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.

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.

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.

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.