[Spice-devel] [PATCH v2] red-parse-qxl: Check consistency of QXL_DRAW_COPY operations

[Francois Gouget]

On Wed, 1 Jun 2016, Frediano Ziglio wrote:
[...]
> Can I suggest 
> 
> @@ -682,6 +682,20 @@ static int red_get_copy_ptr(RedMemSlotInfo *slots, int group_id,
>          return 1;
>      }
>      red_get_rect_ptr(&red->src_area, &qxl->src_area);
> +    /* The source area should not extend outside the source bitmap or have
> +     * swapped coordinates.
> +     */
> +    if (red->src_area.left < 0 ||
> +        red->src_area.left > red->src_area.right ||
> +        red->src_area.top < 0 ||
> +        red->src_area.top > red->src_area.bottom) {
> +        return 1;
> +    }
> +    if (red->src_bitmap->descriptor.type == SPICE_IMAGE_TYPE_BITMAP &&
> +        (red->src_area.right > red->src_bitmap->u.bitmap.x ||
> +         red->src_area.bottom > red->src_bitmap->u.bitmap.y)) {
> +        return 1;
> +    }
>      red->rop_descriptor  = qxl->rop_descriptor;
>      red->scale_mode      = qxl->scale_mode;
>      red_get_qmask_ptr(slots, group_id, &red->mask, &qxl->mask, flags);
> 
> ?

Sure. As I said it's not clear to me what the exact rules are so I'm 
open to variants.

The other cases like SPICE_IMAGE_TYPE_SURFACE, SPICE_IMAGE_TYPE_JPEG, 
SPICE_IMAGE_TYPE_SURFACE probably also have their own x/y dimensions but 
these are not accessible. So I guess the end users code bits will have 
to be careful in these cases.

Interestingly SPICE_IMAGE_TYPE_QUIC is just a bunch of SpiceChunks so it 
does not have its own x/y dimensions. It does have a data_size field in 
bytes which we should maybe check if we knew the bpp.


-- 
Francois Gouget <fgouget at codeweavers.com>