CVE-2026-18090: Gdk-pixbuf: gdk-pixbuf: heap out-of-bounds read in uncompress() via crafted icns rle block
A flaw was found in gdk-pixbuf. This vulnerability allows a remote attacker to cause a heap out-of-bounds read by providing a specially crafted Apple Icon Image (.icns) file. The uncompress() function, which handles RLE-encoded ICNS icon data, fails to validate the source buffer's boundaries during decompression. This can lead to a denial of service, where the application crashes, or to information disclosure, potentially revealing sensitive data from adjacent memory.
Other sources
Gdk-pixbuf: gdk-pixbuf: heap out-of-bounds read in uncompress() via crafted icns rle block
— Microsoft
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.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What condition in an ICNS file triggers the unsafe reads?
The issue is triggered by an RLE-encoded ICNS resource block whose claimed runs cause decompression to consume bytes beyond the block boundary. The affected routine does not bound-check tag bytes, repeat-value bytes, or run-data bytes against the source block size.
What must happen for an attacker-controlled file to reach the vulnerable code?
An application using gdk-pixbuf must be induced to process a specially crafted Apple Icon Image (.icns) file containing RLE-encoded icon data. User interaction is required according to the supplied severity vector.
What impact should incident triage prioritize?
The reported impacts are application crashes resulting in denial of service and possible disclosure of sensitive data from adjacent heap memory. No integrity impact is indicated by the supplied severity vector.