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@xxxxxxxxxxxxxxx>
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel