On Thu, Feb 19, 2015 at 16:28:44 -0700, Eric Blake wrote: > On 02/19/2015 08:53 AM, Erik Skultety wrote: > > We interpret port values as signed int (convert them from char *), > > so if a negative value is provided in network disk's configuration, > > we accept it as valid, however there's an 'unknown cause' error raised later. > > This error is only accidental because we return the port value in the return code. > > This patch adds just a minor tweak to the already existing check so we > > reject negative values the same way as we reject non-numerical strings. > > > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1163553 > > --- > > src/qemu/qemu_command.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c > > index 743d6f0..c1e9559 100644 > > --- a/src/qemu/qemu_command.c > > +++ b/src/qemu/qemu_command.c > > @@ -2954,7 +2954,7 @@ qemuNetworkDriveGetPort(int protocol, > > int ret = 0; > > > > if (port) { > > - if (virStrToLong_i(port, NULL, 10, &ret) < 0) { > > + if (virStrToLong_i(port, NULL, 10, &ret) < 0 || ret < 0) { > > virReportError(VIR_ERR_INTERNAL_ERROR, > > _("failed to parse port number '%s'"), > > port); > > Won't this still allow wraparound (an extremely large negative input > that gets parsed as positive)? Wouldn't it be better to switch to > virStrToLong_uip to force a positive number parse? The wrap-around case should be handled fine with the existing helper for signed numbers. Actually, when using virStrToLong_uip, we'd need to make sure that the number won't get wrapped as the function is returning an int due to error reporting. I think Erik's patch is actually fine in the context of the code. Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list