Hello! I was struggling to figure out, why xcoral editor no longer worked for me... http://xcoral.free.fr/ Turns out, it interprets depth of 24 as 3 bytes per pixel (I would too), but that value is rejected by XCreateImage now. The editor certainly worked before, but now the call: image = XCreateImage(dpy, DefaultVisual(dpy,DefaultScreen(dpy)), depth, ZPixmap, 0, data, wp, hp, 32, wp * bytes_per_pixel); returns NULL, when bytes_per_pixel is 3 (depth 24) and the program crashes...
XCreateImage gets the bits-per-pixel setting from the pixmap formats of the video driver in use - it should allow 24-bit depth to be stored in 3 bytes if, and only if, the video driver will accept pixmaps in that format. The change introduced by the recent security fix is now it checks to make sure the memory size allocated is large enough, so it won't overflow the buffer when writing to the image, so it's now preventing you from memory corruption. This seems to be a bug in xcoral's use of XCreateImage that we're just finding now due to this check, so marking as NOTOURBUG.
Created attachment 16705 [details] X-server's config file -- has not changed in years a) The exact same source used to compile and work on the exact same X-server configuration (the /etc/X11/XF86Config on the computer has not changed since the XF86 days); b) xcoral does examine the supported depths -- please, take a look at its sources at http://xcoral.free.fr/ ; the code in question is in tbox.c, look for depth==24 test. The program continues to work fine on an Red Hat 4 system, for example, with the same NVidia driver, but with older X11.
I respectfully disagree with Alan and, having provided more details, am reopening the bug.
On Fri, May 23, 2008 at 04:48:26AM -0700, bugzilla-daemon@freedesktop.org wrote: > b) xcoral does examine the supported depths -- please, take a look at its > sources at http://xcoral.free.fr/ ; the code in question is in tbox.c, look for > depth==24 test. You're confusing depth (how many bits are significant per pixel) vs. bpp (how many bits/bytes does it take to store a given pixel). The most common combination is depth 24 (8 each of red, green and blue) but 32bpp (8 topmost bits empty), because operating on packed 24 (depth 24 + 24bpp) is painful. What Alan's saying is that the assumption that depth == b(its)pp is broken (i.e. total size is not bpp * width * height), and only worked before because of a bug in XCreateImage which would happily allow overflows.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.