Created attachment 346319 [details]
An icns file with icns to demonstrate infinite loop/out-of-bounds read

In the load_resources function (io-icns.c:63), inside the size switch (line 101), all the cases set plen or mlen to: blocklen - sizeof (IcnsBlockHeader);
See lines 109, 117, 127, 134, 139, 146, 151, 158 and 163.
blocklen is set in line 95:

blocklen = GUINT32_FROM_BE (header->size);

There are no checks on the size of blocklen and if it is set to less than sizeof (IcnsBlockHeader) (should be 8) there is an integer underflow.

This is dangerous because it's value is later passed to gdk_pixbuf_loader_write (line 262) when size is 256. This allows an attacker to craft a file that will end up calling to a desired loader with a bogus size that is much larger than the actual buffer size.

Possible exploits of the bug: 
1. adding a bmp, or a an ico image data after the header will cause an out-of-buffer read (again when count>actual buffer size). 
2. With a tiff image it would lead to an infinite loop
3. With a gif, a tga or another icns after the header the code will try to allocate as much as count bytes (and most likely fail on a size of 2^32-1)
4. With another icns it is possible to reach another out-of-bounds read that reads zeros and leads to an infinite loop

Certainly there may be more to that but that's what I found from a quick trial and error.

I tested this on Arch Linux and on Ubuntu 16.04.1 (both 32-bit and 64-bit versions).