Fedora Account System
Red Hat Associate
Red Hat Customer
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.
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?
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?
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.
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?
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.
(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.
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.
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.
I've built packages containing the workaround for FE5, FE6, Rawhide.
ppracer packages even
Thanks!
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.
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.
I don't believe this has been fixed yet.
(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.
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!
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
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
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.