Bug 38109 - i915 driver crashes if too few vertices are submitted (Mesa 7.10.2)
Summary: i915 driver crashes if too few vertices are submitted (Mesa 7.10.2)
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: 7.10
Hardware: Other All
: medium major
Assignee: marius predut
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2011-06-09 06:10 UTC by Matthias Hopf
Modified: 2015-09-23 22:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
crash_too_few_vertices.c (794 bytes, text/x-c++src)
2011-06-09 06:10 UTC, Matthias Hopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Hopf 2011-06-09 06:10:31 UTC
Created attachment 47767 [details]
crash_too_few_vertices.c

If too few vertices are submitted in between glBegin()/glEnd() (and probably also for vertex arrays), the stack is overwritten and Mesa crashes without a meaningful stack trace.

By single stepping I found the culprit:

(gdb) bt
#0  intel_render_quads_verts (ctx=0x81ce390, start=0, count=1, flags=55) at ../../../../../src/mesa/tnl_dd/t_dd_dmatmp.h:636
#1  0xb683457a in intel_run_render (ctx=0x81ce390, stage=0x8225468) at intel_render.c:247
#2  0xb691a4c2 in _tnl_run_pipeline (ctx=0x81ce390) at tnl/t_pipeline.c:153
#3  0xb68780eb in intelRunPipeline (ctx=0x81ce390) at intel_tris.c:1075
#4  0xb691ae00 in _tnl_draw_prims (ctx=0x81ce390, arrays=0x8213498, prim=0x8211e6c, nr_prims=1, ib=0x0, min_index=0, max_index=0)
    at tnl/t_draw.c:518
#5  0xb691b3b1 in _tnl_vbo_draw_prims (ctx=0x81ce390, arrays=0x8213498, prim=0x8211e6c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=
    0, max_index=0) at tnl/t_draw.c:424
#6  0xb6911d35 in vbo_exec_vtx_flush (exec=0x8211cf8, unmap=1 '\001') at vbo/vbo_exec_draw.c:381
#7  0xb690f827 in vbo_exec_FlushVertices_internal (ctx=0x81ce390, unmap=1 '\001') at vbo/vbo_exec_api.c:911
#8  0xb690fa38 in vbo_exec_FlushVertices (ctx=0x81ce390, flags=1) at vbo/vbo_exec_api.c:945
#9  0xb68b5b09 in _mesa_LoadMatrixf (m=0x8086e80) at main/matrix.c:353

(gdb) n
630           INIT(GL_TRIANGLES);
[...]
(gdb) n
632           for (j = start; j < count-3; j += 4) {
(gdb) p start
$11 = 0
(gdb) p count
$12 = 1
(gdb) p count-3
$14 = 4294967294


Apparently, count isn't validated before, and it's unsigned. Question remains whether this should be tested in some upper Mesa layer, because probably more drivers are affected by this.

Find a glut testcase in the attachment.
Comment 1 Ian Romanick 2011-06-09 10:16:49 UTC
There have been some recent changes in this area on master.  Can you reproduce the bug there?
Comment 2 Matthias Hopf 2011-06-09 10:49:32 UTC
As soon as I've got some spare time I'll do it. Expect results next week or so.
Comment 3 Philipp Spitzer 2012-03-25 14:07:49 UTC
As this might be related with the bug https://bugs.freedesktop.org/show_bug.cgi?id=47859 I compiled the attachment by calling

g++ -lglut -lGL crash_too_few_vertices.c

on Debian with i915 driver and libgl1-mesa-dri-dbg 8.0-2 (from experimental) and it leads to an SIGSEGV, Segmentation fault as described before.
Comment 4 marius predut 2015-09-09 12:19:19 UTC
A patch that fix this was submitted to the mesa mailing list.
Comment 5 Ian Romanick 2015-09-23 22:35:05 UTC
Fixed by the following patch series.  These should get picked to Mesa 11.0.1 and whatever the next 10.6.x release is.

commit 25543d8ec506ef32599af6f5e0dd735e01b39909
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 14 11:59:22 2015 -0700

    t_dd_dmatmp: Use addition instead of subtraction in loop bounds
    
    This is used everywhere else in this file because it avoids problems
    when count is zero (due to trimming).
    
    No piglit regressions on i915 (G33) or radeon (Radeon 7500).
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Cc: Marius Predut <marius.predut@intel.com>
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

commit c0b3b2f7603eab210acdb2e654e5411fe912ca34
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 14 11:56:20 2015 -0700

    t_dd_dmatmp: Pull out common 'count -= count & 3' code
    
    This was missing in the HAVE_TRIANGLES path, and that could cause
    incorrect rendering.
    
    No piglit regressions on i915 (G33) or radeon (Radeon 7500).
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Cc: Marius Predut <marius.predut@intel.com>
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

commit 0d475ee2b989ac1697720ca391913e9158156bdc
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 14 11:50:28 2015 -0700

    t_dd_dmatmp: Use '& 3' instead of '% 4' everywhere
    
    No piglit regressions on i915 (G33) or radeon (Radeon 7500).
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

commit fad8d54de7e7f908cb0d06f0b54af8440e689928
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 14 11:46:50 2015 -0700

    t_dd_dmatmp: Clean up improper code formatting from previous patch
    
    No piglit regressions on i915 (G33) or radeon (Radeon 7500).
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

commit d7bf7969b90f66ee614f2d2225f3a821d5396a89
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 14 11:37:12 2015 -0700

    t_dd_dmatmp: Make "count" actually be the count
    
    The value passed in count previously was "vertex after the last vertex
    to be processed."  Calling that "count" was misleading and kind of mean.
    Looking at the code, many functions immediately do "count-start" to get
    back the true count.  That's just silly.
    
    If it is better for the loops to be 'for (j = start; j < (start +
    count); j++)', GCC will do that transformation.
    
    NOTE: There is some strange formatting left by this patch.  That was
    done to make it more obvious that the before and after code is
    equivalent.  These will be fixed in the next patch.
    
    No piglit regressions on i915 (G33) or radeon (Radeon 7500).
    
    v2: Fix a remaining (count-start) in render_quad_strip_verts.
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Brian Paul <brianp@vmware.com> [v1]
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>


bug/show.html.tmpl processed on Mar 26, 2017 at 13:02:21.
(provided by the Example extension).