[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 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

Attachment: pgpIb2Yeq2H4d.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]