REDHAT-BUG-2517751: Low severity Gnome GDK-PixBuf vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
What must an attacker provide to trigger the issue?
A crafted .icns file containing a truncated RLE-compressed icon block can trigger it. An il32 block whose declared block length covers only its header and has no payload is given as an example.
Which icon data types are implicated?
The affected RLE-compressed ICNS block types are is32 (16x16), il32 (32x32), ih32 (48x48), and it32 (128x128). The unsafe reads occur while decoding their RLE data.
What is the practical impact of processing a malicious file?
The decoder can read beyond the mapped or allocated ICNS data. This can crash the process or copy adjacent heap bytes into decoded pixel data.
How can I assess whether a file is a likely trigger?
Inspect RLE-compressed ICNS blocks for a declared block length that does not include enough payload bytes for the decoder's reads. A block consisting only of its header with zero payload is specifically identified as a triggering condition.