On Tue, 27 Jun 2023 at 14:07, <marcandre.lur...@redhat.com> wrote:
>
> From: Marc-André Lureau <marcandre.lur...@redhat.com>
>
> Allocate pixman bits for scanouts with qemu_win32_map_alloc() so we can
> set a shareable handle on the associated display surface.
>
> Note: when bits are provided to pixman_image_create_bits(), you must also give
> the rowstride (the argument is ignored when bits is NULL)
>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> Message-Id: <20230606115658.677673-11-marcandre.lur...@redhat.com>

Hi; Coverity notes (CID 1516557) that this introduces
a possible division-by-zero (different from the one
Alex's fuzzer found):

> @@ -1252,15 +1281,23 @@ static int virtio_gpu_load(QEMUFile *f, void *opaque, 
> size_t size,
>              g_free(res);
>              return -EINVAL;
>          }
> +
> +        res->hostmem = calc_image_hostmem(pformat, res->width, res->height);
> +#ifdef WIN32
> +        bits = qemu_win32_map_alloc(res->hostmem, &res->handle, &error_warn);
> +        if (!bits) {
> +            g_free(res);
> +            return -EINVAL;
> +        }
> +#endif
>          res->image = pixman_image_create_bits(pformat,
>                                                res->width, res->height,
> -                                              NULL, 0);
> +                                              bits, res->hostmem / 
> res->height);

In this function we've just pulled res->height out of the
incoming migration stream, and we haven't done any sanity
checking on it. So it might be 0, in which case this division
will divide by zero and fall over.

thanks
-- PMM

Reply via email to