Bug 88880 - glxextensions.c: buffer overflow and incorrect zeroing
Summary: glxextensions.c: buffer overflow and incorrect zeroing
Status: RESOLVED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-30 20:43 UTC by Heinrich Schuchardt
Modified: 2015-02-11 19:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Heinrich Schuchardt 2015-01-30 20:43:33 UTC
In
src/glx/x11/glxextensions.c
a bit field server_support is used for a bitfield. Unfortunately length of the bitfield is not correctly considered when accessing the field.

In the following code fragment the length of the zeroed memory is the length of the pointer (4 bytes in case of a 32bit system) not the length of the data the pointer points to (__GL_EXT_BYTES bytes).

static void
__glXProcessServerString( const struct extension_info * ext,
			  const char * server_string,
			  unsigned char * server_support )
{
   unsigned  base;
   unsigned  len;

   (void) memset( server_support, 0, sizeof( server_support ) );

Furthermore the length of the memory area pointed to by server_support
is defined in varying ways in the coding:

#define __GL_EXT_BYTES   ((__NUM_GL_EXTS + 7) / 8)

unsigned char server_support[ __GL_EXT_BYTES ];
unsigned char server_support[8];

Currently __NUM_GL_EXTS = 132, so __GL_EXT_BYTES = 9.

So where server_support[8] is used a buffer overflow by setting a bit may occur.

__GL_EXT_BYTES should always be used to refer to the length of the bitfield.

This problem was identified with cppcheck.
http://cppcheck.sourceforge.net/

Best regards

Heinrich Schuchardt
Comment 1 Matt Turner 2015-02-03 01:37:28 UTC
Would be nice to explain why you decided the bug was invalid.
Comment 2 Ian Romanick 2015-02-11 19:44:50 UTC
It's invalid because the code referenced in the bug report was removed by commit 7ef4a07 in July 2006.  I think it's time for any upgrade. :)

See also bug #7353.


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.