To my knowledge, the limit is 16 on r300.
(the docs don't say what the limit is)

The lack of bounds checking can be abused to do all sorts of things
(from bypassing parts of the CS checker to crashing the kernel).

Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=36745

Cc: sta...@kernel.org
Signed-off-by: Marek Olšák <mar...@gmail.com>
---
 drivers/gpu/drm/radeon/r100_track.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100_track.h 
b/drivers/gpu/drm/radeon/r100_track.h
index 2fef9de..686f9dc 100644
--- a/drivers/gpu/drm/radeon/r100_track.h
+++ b/drivers/gpu/drm/radeon/r100_track.h
@@ -63,7 +63,7 @@ struct r100_cs_track {
        unsigned                        num_arrays;
        unsigned                        max_indx;
        unsigned                        color_channel_mask;
-       struct r100_cs_track_array      arrays[11];
+       struct r100_cs_track_array      arrays[16];
        struct r100_cs_track_cb         cb[R300_MAX_CB];
        struct r100_cs_track_cb         zb;
        struct r100_cs_track_cb         aa;
@@ -146,6 +146,12 @@ static inline int r100_packet3_load_vbpntr(struct 
radeon_cs_parser *p,
        ib = p->ib->ptr;
        track = (struct r100_cs_track *)p->track;
        c = radeon_get_ib_value(p, idx++) & 0x1F;
+       if (c > 16) {
+           DRM_ERROR("Only 16 vertex buffers are allowed %d\n",
+                     pkt->opcode);
+           r100_cs_dump_packet(p, pkt);
+           return -EINVAL;
+       }
        track->num_arrays = c;
        for (i = 0; i < (c - 1); i+=2, idx+=3) {
                r = r100_cs_packet_next_reloc(p, &reloc);
-- 
1.7.4.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to