[virt-tools-list] [PATCH virt-viewer 15/19] Hook up handling of Monitors

[Christophe Fergeau]

On Tue, Jul 17, 2012 at 02:38:15PM +0200, Marc-André Lureau wrote:
> On Tue, Jul 17, 2012 at 2:15 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> > On Mon, Jul 16, 2012 at 06:57:50PM +0200, Marc-André Lureau wrote:
> >> +    g_object_get(channel,
> >> +                 "monitors", &monitors,
> >> +                 "monitors-max", &monitors_max,
> >> +                 NULL);
> >> +    g_return_if_fail(monitors != NULL);
> >> +    g_return_if_fail(monitors->len <= monitors_max);
> >
> > Is monitors-max coming from the network? If so, should we make sure it's
> > not very huge to avoid allocating too much memory?
> 
> I don't know what would be very huge, probably >16 starts to be
> *really* a lot already, but if it's what's the server has..

I'm concerned about malicious payload putting a huge number there for a
nasty purpose. Moreover, is this value coming from the server, or is it
coming from the qxl driver in the guest?


> Yes, corrected. I wonder if it wouldn't be simpler to have only the
> fallback version.. What do you think?

This would get rid of various #ifdef so this sounds good to me.

> >> +    g_clear_pointer(&monitors, g_array_unref);
> >
> > This is very new in glib, do we have a fallback definition for this symbol?
> 
> No, adding it to glib-compat.h.

I just realized that g_array_unref is glib 2.22+

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20120717/dfd5d843/attachment.sig>