i965: Assert that the offset in the VBO is below the VBO size.

This avoids sending a bad buffer address to the GPU due to programmer error,
and is permitted by the ARB_vbo spec.  Note that we still have the opportunity
to dereference past the end of the GPU, because we aren't clipping to a
correct _MaxElement, but that appears to be harder than it should be.  This
gets us the 90% solution.

Bug #19911.
(cherry picked from commit d7430d942f6c7950a92367aeb13b80cf76ccad78)

1 files changed, 14 insertions, 0 deletions

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index e7a87b6e09..05079c043a 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -396,6 +396,20 @@ static void brw_prepare_vertices(struct brw_context *brw)
 	 dri_bo_reference(input->bo);
 	 input->offset = (unsigned long)input->glarray->Ptr;
 	 input->stride = input->glarray->StrideB;
+
+	 /* This is a common place to reach if the user mistakenly supplies
+	  * a pointer in place of a VBO offset.  If we just let it go through,
+	  * we may end up dereferencing a pointer beyond the bounds of the
+	  * GTT.  We would hope that the VBO's max_index would save us, but
+	  * Mesa appears to hand us min/max values not clipped to the
+	  * array object's _MaxElement, and _MaxElement frequently appears
+	  * to be wrong anyway.
+	  *
+	  * The VBO spec allows application termination in this case, and it's
+	  * probably a service to the poor programmer to do so rather than
+	  * trying to just not render.
+	  */
+	 assert(input->offset < input->bo->size);
       } else {
 	 if (input->bo != NULL) {
 	    /* Already-uploaded vertex data is present from a previous