Bug 1159171

Summary:	vshCommandOptScaledInt should reject negative value and void inaccurate error message
Product:	Red Hat Enterprise Linux 7	Reporter:	Jincheng Miao <jmiao>
Component:	libvirt	Assignee:	Pavel Hrdina <phrdina>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	dyuan, fjin, honzhang, mzhan, rbalakri
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	libvirt-1.2.16-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-11-19 05:54:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jincheng Miao 2014-10-31 06:31:41 UTC

Description of problem:

Function vshCommandOptScaledInt() has two steps to deal with negative value:
1. it will parse negative numbers as their twos-complement positive counterpart by virStrToLong_ull().

2. it will scale by virScaleInteger(). But the input value is very large, it will report 'numerical overflow', like:

virsh # blockresize --size -2048 test vda
error: Unable to parse integer
error: numerical overflow: value too large: 18446744073709549568

This error message came out from step 2, and it is not clear for the users.

Some virsh commands use this functon:
blockresize, setmem, setmaxmem, freepages, allocpages.

IMHO, this function shouldn't accept negative number, because negative value is meaningless in this situation. Reject negative number could be a good choice.

version:
libvirt-1.2.8-2.el7.x86_64
qemu-kvm-rhev-2.1.0-3.el7.x86_64

How reproducible:
100%

Step to reproduce:
1. choose a virsh command in blockresize, setmem, setmaxmem, freepages, allocpages

2. pass negative value
# virsh blockresize --size -2048 test vda
error: Unable to parse integer
error: numerical overflow: value too large: 18446744073709549568

Expect results:
in step2, do not show numerical overflow error.

Comment 1 Pavel Hrdina 2015-05-22 14:02:13 UTC

Upstream patch proposed:

https://www.redhat.com/archives/libvir-list/2015-May/msg00828.html

Comment 2 Pavel Hrdina 2015-05-25 07:13:29 UTC

Upstream commit

commit 739ea3ce783e2ffbf6699b82f6020b613fef5f44
Author: Pavel Hrdina <phrdina>
Date:   Fri May 22 15:56:57 2015 +0200

    virsh: reject negative values for scaled integer
    
    Some virsh commands have a size parameter, which is handled as scaled
    integer.  We don't have any *feature* that would allow to use '-1' as
    maximum size, so it's safe to reject any negative values for those
    commands.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1159171
    
    Signed-off-by: Pavel Hrdina <phrdina>


v1.2.15-145-g739ea3c

Comment 5 Fangge Jin 2015-08-25 11:37:04 UTC

I can reproduce this bug on build libvirt-1.2.8-2.el7.x86_64

Verify this bug on build libvirt-1.2.17-6.el7.x86_64

Steps:
# virsh blockresize --size -2048 rhel6.6-GUI vda
error: Numeric value '-2048' for <size> option is malformed or out of range

# virsh blockresize --size -2 rhel6.6-GUI vda
error: Numeric value '-2' for <size> option is malformed or out of range

# virsh setmem rhel6.6-GUI --size -2048
error: Numeric value '-2048' for <size> option is malformed or out of range

# virsh setmaxmem rhel6.6-GUI --size -2048
error: Numeric value '-2048' for <size> option is malformed or out of range

# virsh freepages --cellno 0 --pagesize -2048
error: Numeric value '-2048' for <pagesize> option is malformed or out of range

# virsh allocpages --cellno 0 --pagesize -2048 --pagecount 0
error: Numeric value '-2048' for <pagesize> option is malformed or out of range

Comment 7 errata-xmlrpc 2015-11-19 05:54:59 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html