Bug 199011 - 256x255 instead of 256x256 texture causes bufferoverrun.
256x255 instead of 256x256 texture causes bufferoverrun.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
bzcl34nup
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-15 12:45 EDT by Hans de Goede
Modified: 2009-07-14 12:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:47:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-07-15 12:45:14 EDT
I found this while running ppracer trough electricfence in an attempt to find a
problem with the opensource r300 drivers in combination with ppracer.

The file: /usr/share/ppracer/courses/themes/models/common/tree.png is 256x255,
this causes a buffer overrun somwhere in GLU. Resizing the file to 256x256 using
gimp (I only resized the canvas adding a row of transparant pixels) fixes this
bufferoverrun.
Comment 1 Hans de Goede 2006-11-13 07:36:49 EST
Erm, ping? Since this is an FE package, I can fix this myself in CVS and request
a build if you want is that ok?
Comment 2 Nils Philippsen 2006-11-15 08:10:12 EST
Sorry for the packet loss...

My take on this is that this is a bug in libGLU (unless it says somewhere that
there are constraints on the texture dimensions). What do you think?
Comment 3 Hans de Goede 2006-11-15 10:04:17 EST
Nah, this is a long time ago now but I don't remember the details, looking at
this again I think that the problem is that ppracer passes a buffer from libpng
to glu and says it is 256x256 big, iow ppracer is hardcoded to 256x256, which is
ok, except that the image isn't this size.
Comment 4 Nils Philippsen 2006-11-16 11:11:05 EST
I've looked a bit at this and found that in src/textures.cpp[152] in
load_texture(), when running this piece of code (print_debug() inserted by me), ...

[...]
    print_debug( DEBUG_TEXTURE, "gluBuild2DMipmaps(%d, %d, %d, %d, %d, %d, %p)",
GL_TEXTURE_2D, texImage->depth, texImage->width,
             texImage->height, texImage->depth == 3 ? GL_RGB : GL_RGBA,
             GL_UNSIGNED_BYTE, texImage->data);
    
    gluBuild2DMipmaps( GL_TEXTURE_2D, texImage->depth, texImage->width,
               texImage->height, texImage->depth == 3 ? GL_RGB : GL_RGBA,
               GL_UNSIGNED_BYTE, texImage->data );
[...]

... it calls the function with 256x255, as seen in the debugging output ('set
debug="texture"' in .ppracer/options):

[...]
ppracer debug (texture): Loading texture ac/tree.png from file: tree.png
ppracer debug (texture): gluBuild2DMipmaps(3553, 4, 256, 255, 6408, 5121, 0x9b44e70)
ppracer debug (texture): Binding ac/tree.png to texture name: ac/tree.png
[...]

What am I missing?
Comment 5 Panu Matilainen 2006-11-16 13:26:17 EST
It's a bug in the r300 driver: https://bugs.freedesktop.org/show_bug.cgi?id=8348
- resizing the image didn't fix this crash for me btw.
Comment 6 Hans de Goede 2006-11-16 14:22:47 EST
(In reply to comment #4)
> I've looked a bit at this and found that in src/textures.cpp[152] in
> load_texture(), when running this piece of code (print_debug() inserted by
me), ...
> 
> [...]
>     print_debug( DEBUG_TEXTURE, "gluBuild2DMipmaps(%d, %d, %d, %d, %d, %d, %p)",
> GL_TEXTURE_2D, texImage->depth, texImage->width,
>              texImage->height, texImage->depth == 3 ? GL_RGB : GL_RGBA,
>              GL_UNSIGNED_BYTE, texImage->data);
>     
>     gluBuild2DMipmaps( GL_TEXTURE_2D, texImage->depth, texImage->width,
>                texImage->height, texImage->depth == 3 ? GL_RGB : GL_RGBA,
>                GL_UNSIGNED_BYTE, texImage->data );
> [...]
> 
> ... it calls the function with 256x255, as seen in the debugging output ('set
> debug="texture"' in .ppracer/options):
> 
> [...]
> ppracer debug (texture): Loading texture ac/tree.png from file: tree.png
> ppracer debug (texture): gluBuild2DMipmaps(3553, 4, 256, 255, 6408, 5121,
0x9b44e70)
> ppracer debug (texture): Binding ac/tree.png to texture name: ac/tree.png
> [...]
> 
> What am I missing?

Ah, good catch, as said this is a long time ago, so I didn't remember properly.
In that case I see your point concidering this a bug in libGLU. May I suggest
the following:
1) Fix this by making the image 256x256 (as a workaround for now) and
2) file this as a bug against libGLU


(In reply to comment #5)
> It's a bug in the r300 driver: https://bugs.freedesktop.org/show_bug.cgi?id=8348
> - resizing the image didn't fix this crash for me btw.

As said I've hit this when debugging another r300 bug (ppracer works fine for me
now), but this is not related to the r300 problem the crash only happens when
using electricfence, otherwise this bufferoverrun appears todo no harm, but that
appears is quite dangerous!

When run with electricfence the crash was deep in libGLu, so I doubt the r300 is
involved in this 256x255 problem.
Comment 7 Nils Philippsen 2006-11-21 10:51:11 EST
Hans, I agree, would you commit your fixed image to CVS and either build or ping
me so that I can build (whatever suits you best)?

I'll change product to Fedora Core and component to mesa for fixing this in
libGLU and set the "Security" keyword because there's a faint theoretical risk
that apps use libGLU to render images from unchecked sources as textures.
Comment 8 Hans de Goede 2006-11-22 16:45:17 EST
Okay, I've added a fixed tree.png to the devel branch under CVS, notice that the
spec file still needs updating to copy this to the correct location at the end
of %install, release bump, clog entry etc.
Comment 9 Nils Philippsen 2006-11-24 05:40:03 EST
I've built packages containing the workaround for FE5, FE6, Rawhide.
Comment 10 Nils Philippsen 2006-11-24 05:44:21 EST
ppracer packages even
Comment 11 Hans de Goede 2006-11-24 05:48:25 EST
Thanks!
Comment 12 Nils Philippsen 2007-09-05 08:51:36 EDT
Adam, have there been any changes yet in libGLU which fix this? I'm wondering if
I can remove the workaround from the ppracer packages.
Comment 13 Bug Zapper 2008-04-03 13:47:37 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 14 Hans de Goede 2008-04-04 04:17:39 EDT
I don't believe this has been fixed yet.
Comment 15 Hans de Goede 2008-04-04 05:12:39 EDT
(In reply to comment #14)
> I don't believe this has been fixed yet.
> 

Erm, that should read (clearer):
I believe this has not been fixed yet.
Comment 16 Lubomir Kundrak 2008-04-08 16:00:23 EDT
Final Freeze is in effect now. Security fixes almost certainly warrant a freeze
break, so in case you build a fix for this, mail release engineering as
described here: [2]

[1] https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00007.html
[2] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

Thanks!
Comment 17 Bug Zapper 2008-05-13 22:13:52 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2009-06-09 18:13:20 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2009-07-14 12:47:35 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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