XF86DRIGetClientDriverName crashes when running glxinfo, glgears etc -> operating system issue

[Forest]

I am running Virtual Box 4.2.16 along with the VBox additions 4.2.16 in a Windows 7.0 host. I am running a CentOS 6.4 VM. Mostly everything is working correctly. However, glxinfo segfaults on a call to XF86DRIGetClientDriverName with the following stack trace (optimized libGL):

0x0000003225289831 in memcpy () from /lib64/libc.so.6
1 0x0000003229242417 in _XRead () from /usr/lib64/libX11.so.6
2 0x0000003229242509 in _XReadPad () from /usr/lib64/libX11.so.6
3 0x0000003c72048921 in XF86DRIGetClientDriverName () from /usr/lib64/libGL.so.1
4 0x0000003c72046a97 in ?? () from /usr/lib64/libGL.so.1
5 0x0000003c72046e5e in ?? () from /usr/lib64/libGL.so.1
6 0x0000003c72020d1d in ?? () from /usr/lib64/libGL.so.1
7 0x0000003c7201d92d in ?? () from /usr/lib64/libGL.so.1
8 0x0000003c7201ea8f in glXChooseVisual () from /usr/lib64/libGL.so.1
9 0x000000000040163e in ?? ()
10 0x0000000000402d8a in ?? ()
11 0x000000322521ecdd in libc_start_main () from /lib64/libc.so.6

I ran into the problem with running paraview but found running glxinfo dies in the same place.

My xorg.conf file is this:

# VirtualBox generated configuration file # based on /etc/X11/xorg.conf.

Section "Monitor" Identifier "Monitor[0]" ModelName "VirtualBox Virtual Output" VendorName "Oracle Corporation" EndSection

Section "Device" BoardName "VirtualBox Graphics" Driver "vboxvideo" Identifier "Device[0]" VendorName "Oracle Corporation" EndSection

Section "Screen" SubSection "Display" Depth 24 EndSubSection Device "Device[0]" Identifier "Screen[0]" Monitor "Monitor[0]" EndSection

I tried disabling the 3D acceleration but this did not solve the problem.

I was able to get around the problem by changing the graphics driver to vesa, but that doesn't behave very well in terms of interacting with the windows host using VBoxAdditions.

I searched the bug DB and did find a reference to a bug reported 4 years ago with a crash in vboxstub_glXMakeCurrent in the VirtualBox 3.1.2 version:

https://www.virtualbox.org/ticket/4674

I have attached all of the VBox log files as a tar archive.

[Forest]

VBox log files

[Michael Thayer]

This is easy to reproduce, but so far I can't see what is going wrong. On the client code there should have been no VirtualBox code executed at all - or even loaded - at the time the segmentation fault happens, as it happens while the application is querying the X server for the name of the driver to load. I haven't checked what the X server is doing yet, but at least the name length of the driver name sent by the X server is correct, so I am puzzled as to why the name should not be readable. At least at this stage I am suspecting some X server problem because our X.Org driver does something differently to what the server is expecting.

[Michael Thayer]

Debugging the X server side of this I can't see anything wrong either. I suggest that you take it up with CentOS/RedHat, as they will have people who know much better than me what is going on inside their X server. You might even point them to this ticket to simplify communication.

[Michael Thayer]

Ah, it looks like a typing mistake on line 309 of XF86dri.c, function XF86DRIGetClientDriverName(), which reads

clientDriverName = calloc(rep.clientDriverNameLength + 1, 1);

instead of

*clientDriverName = calloc(rep.clientDriverNameLength + 1, 1);

[Michael Thayer]

Closing this as a problem with the CentOS 6.4 Mesa package.

[Michael Thayer]

For information,

commit 306f630e676eb901789dd09a0f30d7e7fa941ebe Author: Alan Coopersmith <> Date: Fri Apr 26 16:33:03 2013 -0700

integer overflow in XF86DRIGetClientDriverName() [CVE-2013-1993 2/2]

clientDriverNameLength is a CARD32 and needs to be bounds checked before adding one to it to come up with the total size to allocate, to avoid integer overflow leading to underallocation and writing data from the network past the end of the allocated buffer.

NOTE: This is a candidate for stable release branches.

Reported-by: Ilja Van Sprundel <> Signed-off-by: Alan Coopersmith <> Reviewed-by: Brian Paul <>

So probably fixed in Mesa 9.1 but not back-ported to the version CentOS 6.4 is supplying.

[Michael Thayer]

No that isn't the right commit. I am better with Subversion than with Git.

[Michael Thayer]

After a little more investigation, I found this to be caused by the RedHat source patch "mesa-integer-overflows-CVE-2013-1993.patch". Relevant extract:

@@ -300,9 +305,11 @@ XF86DRIGetClientDriverName(Display * dpy
    *ddxDriverPatchVersion = rep.ddxDriverPatchVersion;
 
    if (rep.length) {
-      if (!
-          (*clientDriverName =
-           (char *) Xcalloc(rep.clientDriverNameLength + 1, 1))) {
+      if (rep.clientDriverNameLength < INT_MAX)
+         clientDriverName = calloc(rep.clientDriverNameLength + 1, 1);
+      else
+         clientDriverName = NULL;
+      if (clientDriverName == NULL) {
          _XEatData(dpy, ((rep.clientDriverNameLength + 3) & ~3));
          UnlockDisplay(dpy);
          SyncHandle();