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

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

 



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@xxxxxxxxxx> 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: pgpo7AgxAHnr9.pgp
Description: PGP signature


[Index of Archives]     [Linux Virtualization]     [KVM Development]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]

  Powered by Linux