Bug 135675
| Summary: | Problems with netpbm generated BMPs from 4 colour images | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nils Philippsen <nphilipp> | ||||||||
| Component: | netpbm | Assignee: | Jindrich Novy <jnovy> | ||||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Ben Levenson <benl> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | rawhide | CC: | alan, bressers, mjc, nphilipp, pknirsch | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2004-10-25 11:17:02 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Nils Philippsen
2004-10-14 11:29:06 UTC
Created attachment 105194 [details]
BMP file that exposes the problem.
Attached as application/octet-stream to not confuse browsers.
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).
As the crash/core dump is induced by g_assert_not_reached, this doesn't seem to be a security problem anymore. 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. 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. Reassigning this to netpbm. 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:
------snip------
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",
cmdline_p->bpp);
}
------snip------
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 ;-)
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? Created attachment 105368 [details]
fixes the bmp colour-depth problem
Nils, this patch should tell ppmtobmp to behave less destructive to the gimp.
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 ;-) 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. This has been fixed upstream since netpbm-10.21. |