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).
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
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
In either case, adding something like
if (ntri >= INT_MAX/sizeof (xTriangle))
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)...
closing as unreproducible
on Jan 21, 2017 at 06:29:06.
(provided by the Example extension).