OSDN Git Service

gallium/vbuf: avoid segfault when we get invalid glDrawRangeElements()
authorBrian Paul <brianp@vmware.com>
Mon, 19 Jun 2017 18:22:09 +0000 (12:22 -0600)
committerAndres Gomez <agomez@igalia.com>
Wed, 28 Jun 2017 17:15:05 +0000 (20:15 +0300)
A common user error is to call glDrawRangeElements() with the 'end'
argument being one too large.  If we use the vbuf module to translate
some vertex attributes this error can cause us to read past the end of
the mapped hardware buffer, resulting in a crash.

This patch adjusts the vertex count to avoid that issue.  Typically,
the vertex_count gets decremented by one.

This fixes crashes with the Unigine Tropics and Sanctuary demos with older
VMware hardware versions.  The issue isn't hit with VGPU10 because we
don't hit this fallback.

No piglit changes.

CC: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit d8148ed10ae5faea6f88f2f964797f4b0590c083)
[Andres Gomez: pipe_vertex_buffer hadn't shrunk yet]
Signed-off-by: Andres Gomez <agomez@igalia.com>
Conflicts:
src/gallium/auxiliary/util/u_vbuf.c

src/gallium/auxiliary/util/u_vbuf.c

index f040f4a..7d4a44b 100644 (file)
@@ -423,8 +423,22 @@ u_vbuf_translate_buffers(struct u_vbuf *mgr, struct translate_key *key,
          unsigned size = vb->stride ? num_vertices * vb->stride
                                     : sizeof(double)*4;
 
-         if (offset+size > vb->buffer->width0) {
+         if (offset + size > vb->buffer->width0) {
+            /* Don't try to map past end of buffer.  This often happens when
+             * we're translating an attribute that's at offset > 0 from the
+             * start of the vertex.  If we'd subtract attrib's offset from
+             * the size, this probably wouldn't happen.
+             */
             size = vb->buffer->width0 - offset;
+
+            /* Also adjust num_vertices.  A common user error is to call
+             * glDrawRangeElements() with incorrect 'end' argument.  The 'end
+             * value should be the max index value, but people often
+             * accidentally add one to this value.  This adjustment avoids
+             * crashing (by reading past the end of a hardware buffer mapping)
+             * when people do that.
+             */
+            num_vertices = (size + vb->stride - 1) / vb->stride;
          }
 
          map = pipe_buffer_map_range(mgr->pipe, vb->buffer, offset, size,