Bernhard Reutner-Fischer wrote:
$ git log 7307e06122997f3d5e0108cd1bab4b11a1d5ebdc^..7307e06122997f3d5e0108cd1bab4b11a1d5ebdc miscutils/fbsplash.c commit 7307e06122997f3d5e0108cd1bab4b11a1d5ebdc Author: Bernhard Reutner-Fischer Date: Wed Feb 18 15:28:43 2009 +0000- bail out if screen resolution does not match PPM dimensions. Previously a 640x480 PPM on an e.g. 720x400 console would just segfault when reading the lines. While this bug should perhaps be fixed to handle such cases properly we just exit gracefully until somebody is willing to take care of it properly.
Looking at the code I don't see how this can be possible, and I tested with a 1024x768 ppm on a 800x600 screen.
The read is done of "line_size" bytes, which is the original image width * 3, into a buffer allocated with "line_size" bytes, so where is the segfault?
The loops are upper limited by min(image height,screen height) and min(image width,screen width) so it can't access memory outside the framebuffer size (the start address -- "src" -- is recalculated on each scanline).
It seems to me this is a false alarm, maybe from a previous version of fbsplash where this could happen.
Any commments? Regards, ~Nuno Lucas _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
