Bug 135675 - Problems with netpbm generated BMPs from 4 colour images
Summary: Problems with netpbm generated BMPs from 4 colour images
Alias: None
Product: Fedora
Classification: Fedora
Component: netpbm (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-14 11:29 UTC by Nils Philippsen
Modified: 2013-07-02 23:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-25 11:17:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
BMP file that exposes the problem. (320.07 KB, application/octet-stream)
2004-10-14 11:31 UTC, Nils Philippsen
no flags Details
Proposed patch (552 bytes, patch)
2004-10-14 11:36 UTC, Nils Philippsen
no flags Details | Diff
fixes the bmp colour-depth problem (808 bytes, patch)
2004-10-18 10:40 UTC, Jindrich Novy
no flags Details | Diff

Description Nils Philippsen 2004-10-14 11:29:06 UTC
Description of problem:

---------- Forwarded message ----------
Date: Tue, 12 Oct 2004 22:23:48 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: [vendor-sec] BMP problems

On the same subject here's a .bmp file that crashes gimp (gimp catches
the plugin error and prints diagnostics). Ironically the file itself
isnt hand crafted but a chance output from netpbm ...

I've verified this in gimp-2.0.5-3. Although I think the chance that
this bug has opened security holes is minute, because it runs against
a g_assert_not_reached(), I've set severity to "security" and closed
access (you never know...). We can always open it up later.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Nils Philippsen 2004-10-14 11:31:13 UTC
Created attachment 105194 [details]
BMP file that exposes the problem.

Attached as application/octet-stream to not confuse browsers.

Comment 2 Nils Philippsen 2004-10-14 11:36:47 UTC
Created attachment 105195 [details]
Proposed patch

This patch checks for valid values of bpp upon entering ReadImage(). If bpp is
invalid, it reports "Invalid number of bits per pixel." and returns -1 (which
is how ReadImage() reports errors to the caller).

Comment 3 Nils Philippsen 2004-10-14 11:58:00 UTC
As the crash/core dump is induced by g_assert_not_reached, this
doesn't seem to be a security problem anymore.

Comment 4 Alan Cox 2004-10-14 12:28:33 UTC
Cool. I've finished testing other apps and they all seem to correctly
error it. Note that you can generate a file with this problem by
feeding a 2 colour image to ppmtobmp so once gimp is fixed this bug
wants reassigning to netpbm 8)

Agree its not a security issue based on your analysis.

Comment 5 Nils Philippsen 2004-10-14 16:03:16 UTC
gimp-2.0.5-0.fc2.2 for FC2 and gimp-2.0.5-4 for Rawhide with the fixed
BMP plugin are on the way.

Comment 6 Nils Philippsen 2004-10-14 16:30:50 UTC
Reassigning this to netpbm.

Comment 7 Jindrich Novy 2004-10-18 09:03:36 UTC
Nils, could you please modify the test for BMP bit depth to include 24
bps bitmaps? Please see snippet from ppmtobmp.c (netpbm-10.25) for
supported BMP bit depths:

if (cmdline_p->bppSpec) {
  if (cmdline_p->bpp != 1 && cmdline_p->bpp != 4 &&
    cmdline_p->bpp != 8 && cmdline_p->bpp != 24)
pm_error("Invalid -bpp value specified: %u.  The only values valid\n"
         "in the BMP format are 1, 4, 8, and 24 bits per pixel",

Alan, this looks like you have found ppmtobmp bug as it says only the
bit depths above are supported when you specify -bpp=foo but it
generates 2bps BMPs with no problem when fed by a 2bps ppm... Note
that the image has actually 4 colours (2bps), so I changed the
summary. (nice Mondrian-like art ;-)

Comment 8 Nils Philippsen 2004-10-18 10:07:01 UTC
Jindrich, I already updated the patch (see my brown paper bug FC2
update last week ;-). Note that BMP supports not only 1, 4, 8, 24 bpp
but also 16 and 32 bpp (at least according to what GIMP people told me
when I reported the error).

Perhaps ppmtobmp should convert the bitdepth to the next larger valid
one, e.g. 2bpp->4bpp?

Comment 9 Jindrich Novy 2004-10-18 10:40:21 UTC
Created attachment 105368 [details]
fixes the bmp colour-depth problem

Nils, this patch should tell ppmtobmp to behave less destructive to the gimp.

Comment 10 Jindrich Novy 2004-10-18 10:48:27 UTC
Nils, yes that's exactly what the patch does. But it has a slight
disadvantage that 16bpp ppm is converted to 24bpp BMP and in case of
32bpp ppm some bad things could occur as ppmtobmp tries to calculate a
histogram of the image and sometimes 4GB of memory is pretty hard to
allocate ;-)

Comment 11 Nils Philippsen 2004-10-18 11:25:01 UTC
That's what I meant -- 16 and 32bpp are also valid, so ppmtobmp should
just convert the data into 16 or 32bpp BMP files respectively (instead
of trying to convert these). Notice that I suggested upward conversion
which shouldn't involve histograms the size of Africa :-P.

Comment 12 Jindrich Novy 2004-10-25 11:17:02 UTC
This has been fixed upstream since netpbm-10.21.

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