Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157110 - bmptopnm does not convert valid bitmaps -- reports error instead and segfaults
Summary: bmptopnm does not convert valid bitmaps -- reports error instead and segfaults
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: netpbm
Version: 4
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-06 21:45 UTC by David Costanzo
Modified: 2013-07-02 23:07 UTC (History)
1 user (show)

Fixed In Version: 10.27-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-09 10:27:24 UTC


Attachments (Terms of Use)
24bpp-320x240.bmp -- a valid bitmap (deleted)
2005-05-06 21:46 UTC, David Costanzo
no flags Details
Proposed fix (deleted)
2005-05-06 22:01 UTC, David Costanzo
no flags Details | Diff

Description David Costanzo 2005-05-06 21:45:08 UTC
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):
netpbm-progs-10.27-1

How reproducible:
Always

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).

Additional info:

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.

Comment 1 David Costanzo 2005-05-06 21:46:41 UTC
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
do.

Comment 2 David Costanzo 2005-05-06 22:01:28 UTC
Created attachment 114106 [details]
Proposed fix

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
functions.

Comment 3 Jindrich Novy 2005-05-09 08:36:27 UTC
Hello David,

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.

Comment 4 Jindrich Novy 2005-05-09 10:27:24 UTC
Fixed & rebuilt.


Note You need to log in before you can comment on or make changes to this bug.