Red Hat Bugzilla – Bug 157110
bmptopnm does not convert valid bitmaps -- reports error instead and segfaults
Last modified: 2013-07-02 19:07:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.7.7-2
Description of problem:
bmptopnm does not convert valid bitmaps. Instead, it reports that the header is bogus.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Execute "bmptopnm 24bpp-320x240.bmp"
Actual Results: bmptopnm prints out:
bmptopnm: Standard Input: unknown Info Header size: 0 bytes
Expected Results: bmptopnm outputs the bitmap as a pnm file to stdout. (At least, I think *think* that's what should happen. I'm new to this toolkit).
I have given this a High severity, even though it's not a crash, memory leak, or loss of data, because it makes the program is useless.
Created attachment 114103 [details]
24bpp-320x240.bmp -- a valid bitmap
This is the bitmap that I used to reproduce the bug. Any valid bitmap should
Created attachment 114106 [details]
The problem is more severe than I thought. The bug is in pm_readlittleshort()
and pm_readlittlelong(), which are called by many other programs within the
toolkit (not just bmptopbm). The bug is that pm_readlittlelong() only called
getch() twice and pm_readlittleshort() only called getch() once.
I checked that similar bugs are NOT present in the big-endian version of these
the high severity is pretty suitable for this as bmptopnm doesn't work at all in
certain cases. I found a memory corruption in the code where it segfaults
because bmptopnm uses uinitialized pointer for colormaps what it tries to free()
at the end in case BMPheader.cmapsize == 0.
Fixed & rebuilt.