Bug 1730

Summary:	__driUtilCreateScreen unitialized memory usage
Product:	Mesa	Reporter:	Owen Taylor <otaylor>
Component:	Other	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high	CC:	dberkholz
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Owen Taylor 2004-10-28 15:31:28 UTC

If a failure occurs early in 
src/mesa/drivers/dri/common/dri_util.c:__driUtilCreateScreen(),
for example if drmOpen() fails, then in the cleanup path
pSAREA, framebuffer.base, framebuffer.dev_priv, are accessed uninitialized,
likely resulting in a segfault.

Fix looks as simple as initializing them to NULL or MAP_FAILED
as appropriate; should be 3 lines.

Comment 1 Ian Romanick 2004-10-28 19:30:45 UTC

It appears that CallCreateNewScreen (src/glx/x11/glxext.c) has the same problem.
 That code does initialize framebuffer.dev_priv, but not the other two fields. 
I replaced the drmOpen call in that file with 'fd = -EPERM', and did *NOT* get a
crash.  I don't understand why GCC doesn't complain about variables being used
without being initialized.  Odd.

Comment 2 Owen Taylor 2004-12-08 06:06:10 UTC

Same as bug 1501 ... multiple trees make it unclear to me whether it
should be dup'ed or not.

Comment 3 Ian Romanick 2005-08-06 09:14:36 UTC

driUtilCreateScreen no longer exists.

Made sure that all the values used in the clean-up code of CallCreateNewScreen
were initialized at some point.  It is still unclear to me as to why GCC did not
complain about the values being used uninitialized..  I suspect the problem may
have been due to the depth of if-statement nesting.

Comment 4 Adam Jackson 2009-08-24 12:22:49 UTC

Mass version move, cvs -> git

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.