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 <[email protected]> > 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
pgpoNIC82xbwX.pgp
Description: PGP signature
_______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
