When running rendertest from XCB xcb/xcb-demo, the Xorg X server crashes partway through. 100% reproducible on a wide variety of graphics architectures, in server versions 6.8-7.0. Marked as a high priority/severity bug because it indicates a potential security flaw. The logged backtrace seems uninformative; good thing it's easy to reproduce this bug.
Created attachment 5355 [details] statically linked XCB rendertest for Linux / x86 This may require the appropriate gcc runtime .so to actually work. Let me know if you have troubles with it.
Created attachment 5369 [details] [review] Patch to correct the allocation size Patch attached to fix the bug (I'm still not rendering what I expected, but that's probably my problem).
yay security
This appears to affect us back to 6.8.0. I can't tell you how happy that makes me. If we need a CVE and coordinated deployment for this, then we should do so _quickly_, such that 7.1 doesn't ship with this.
I'll forward this to vendor-sec, and ask them for the CVE Id. Sorry I didn't notice this report before today. Does May 2. 14:00 UTC sound like a reasonable disclosure date ?
This is now CVE-2006-1526
Created attachment 5468 [details] Xlib/libXrender port of XCB's rendertest.c Here's a quick hack-and-slash backport of enough of rendertest.c to test for this crash from XCB to old-fashioned libX11/libXrender. (At least on Solaris it crashes Xorg 6.9.0, but doesn't crash 6.9.0 + the patch from this bug.)
I've also got a rendercheck test for Triangles that exposes this, which I won't push until we unembargo this.
may 2 is fine for redhat and sun. anyone who has objections should speak up quickly...
This is public now
Fixed in 1.1 branch and head. Moving to block the 1.0 branch tracker, as this clearly needs to be included in any future 1.0.x release. Assigning to me for same.
I have a question about the patch: is the "npoint" parameter of miTriStrip() guaranteed to be checked for an upper bound? If it can get arbitrary ints, then the current patch allows for a trivial integer overflow, and the buffer overflow remains.
In either case, adding something like if (ntri >= INT_MAX/sizeof (xTriangle)) return; right before the allocation can't hurt, just to be on the safe side.
The number of points, tris, etc. is determined from the request size, which is limited. See ProcRenderTriStrip.
FWIW, the attached rendertest.c ("Xlib/libXrender port of XCB's rendertest.c") still crashes X.org 6.8.2 here with the given patch applied.
(In reply to comment #15) Can you provide some details (Xorg.0.log, backtrace, ...) ? It doesn't crash for me one the systems I tried it (and does indeed crash without the patch)...
pitti: ping?
closing as unreproducible
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.