GNOME Bugzilla – Bug 171707
[PATCH] freeze with corrupted bmp
Last modified: 2010-07-10 04:08:39 UTC
Please describe the problem: GQView becomes unresponsive when it browses into a folder with a specially-crafted corrupt bitmap. The bitmap in question is a 4bpp uncompressed image that has no palette (the "colors used" and the "important colors" are both set to zero). After this, GQView no longer accepts mouse input. However, CPU usage is minimal. I have filed a bug on GQView and the maintainer says that he has tracked this down to a bug in GTK+/gdk-pixbuf. He asked me to forward the bug report onto you. I do not know how to test gdk-pixbuf in isolation. If you can tell me how to do this, I will gladly put gdk-pixbuf through a bitmap test suite that I am in the process of creating. Steps to reproduce: Steps to Reproduce: 1) Create a directory called "invalid". 2) Copy 4bpp-no-palette.bmp to that directory. 3) Start GQView 2.1.0. 4) Navigate into the "invalid" directory. Actual results: GQView never shows the contents of the "invalid" directory. GQView is also no longer responsive to any input. I waited at least 30 seconds. Expected results: GQView shows the contents of the "invalid" directory. "4bpp-no-palette.bmp" is shown as a broken image. Does this happen every time? Yes Other information: For reference, the original bug report is on sourceforge is at: https://sourceforge.net/tracker/?func=detail&atid=104050&aid=1168517&group_id=4050
Created attachment 39270 [details] 4bpp-no-palette.bmp -- corrupt bitmap that causes lockup
This might be a duplicate of bug #150601.
Confirmed. This bmp freezes all applications that make use of gdk-pixbuf. Just saved it on my Desktop and found Nautilus chill. There is no load on the CPU thus it is not an infinite loop. libgtk2.0 2.6.2-4 on Debian gtk+ 2.6.4 on Garnome is also affected
This is most certainly *not* a duplicate of bug #150601.
Created attachment 39271 [details] [review] Patch to io-bmp.c to prevent 0 size reallocs This patch fixes the problem by rejecting 0 sized buffers in grow_buffer. Without this, grow_buffer would call g_try_realloc, which would free the buffer, but grow_buffer wouldn't NULL out the state buffer, so later code would try to free it again, leading to a double free.
BTW, David, you can make a trivial test program that calls gdk_pixbuf_new_from_file on various .bmps to test them in isolation.
I have verified that Manish's patch (attachement #39271) fixes the problem.
Yosh, will you commit the fix to both branches ?
Sun Mar 27 19:59:52 2005 Manish Singh <yosh@gimp.org> * io-bmp.c (grow_buffer): reject 0-sized buffers as corrupt header data. Fixes bug #171707.