RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 706887 - [TestOnly] qemu truncates JSON numbers >= 0x8000_0000_0000_0000
Summary: [TestOnly] qemu truncates JSON numbers >= 0x8000_0000_0000_0000
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: pre-dev-freeze
: 7.0
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 612816 (view as bug list)
Depends On:
Blocks: 559201 580953
TreeView+ depends on / blocked
 
Reported: 2011-05-23 11:25 UTC by Richard W.M. Jones
Modified: 2015-03-05 07:19 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 07:19:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
test program (529 bytes, text/plain)
2011-05-23 11:25 UTC, Richard W.M. Jones 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0323 0 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2015-03-05 12:10:54 UTC

Description Richard W.M. Jones 2011-05-23 11:25:08 UTC 
Created attachment 500396 [details]
test program

Description of problem:

qemu's JSON parser truncates numbers which are larger than
LLONG_MAX (0x7fff_ffff_ffff_ffff), replacing them with LLONG_MAX.

This means, for example, the memsave and pmemsave commands are
unsafe since if you supply an address >= LLONG_MAX then it will
read from LLONG_MAX whatever.

Probably other QMP commands are affected by this too.

Version-Release number of selected component (if applicable):

qemu-kvm-0.12.1.2-2.160.el6

How reproducible:

100%

Steps to Reproduce:
1. See the attached C test program.
2.
3.
  
Actual results:

This program always reads from 0x7fff_ffff_ffff_ffff, if
any address >= 0x8000_0000_0000_0000 is used.

Expected results:

Should read from the address given.

Additional info:

The cause is unsafe use of strtoll in json-parser.c at this
line:

static QObject *parse_literal(JSONParserContext *ctxt, QList **tokens)
//...
    case JSON_INTEGER:
        obj = QOBJECT(qint_from_int(strtoll(token_get_value(token), NULL, 10)));

Note that libvirt passes the number over the wire as a long
positive decimal, and qemu does not send back any error message.

Rejected patch sent upstream:

http://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162
Comment 3 Richard W.M. Jones 2011-05-27 13:08:59 UTC 
We obviously didn't get a very satisfactory resolution
to this upstream.

In the meantime we have added a patch to libvirt to send
these large numbers as negative:

http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=78eb8b60d59662271c4a9a1be8c9002ee84dc8cf

If we want to go with just this, we could clone or reassign
this bug to libvirt.  However I still think that qemu is
*broken* here and we should push harder for a fix upstream.
Comment 4 Luiz Capitulino 2011-05-27 15:02:54 UTC 
I agree. However, we're facing a capacity problem in QMP and I'm not sure when I'll be able to fix this, so applying this as an temporary workaround downstream would be good.
Comment 5 Luiz Capitulino 2011-05-27 15:04:03 UTC 
Let me add that I'd like to defer this to 6.3, is it possible to apply the workarond in libvirt and wait until there for the proper fix?
Comment 6 Luiz Capitulino 2011-05-27 15:20:31 UTC 
*** Bug 612816 has been marked as a duplicate of this bug. ***
Comment 7 Luiz Capitulino 2011-05-27 15:21:58 UTC 
Note: this also affects query commands (bug 612816 has examples).
Comment 8 Luiz Capitulino 2011-09-12 14:02:03 UTC 
I'm deferring this to 6.3, because this has a workaround and I have higher priority things to do.
Comment 10 Luiz Capitulino 2011-12-09 19:51:00 UTC 
Due to the same reasons explained in comment 8, I'm deferring this to 6.4.
Comment 11 Ademar Reis 2012-07-12 20:08:51 UTC 
We depend on upstream for this and the fix is not trivial: it may require us to drop the JSON spec and adopt something else for the "wire" protocol, as the previous attempt showed (extensive and tedious discussion at http://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162)

As there's a workaround in libvirt and there's no consequence for users, I'm moving this to RHEL7. Feel free to restart the discussion upstream, but for us it has a low priority and a risk of being closed as WONTFIX.
Comment 16 Markus Armbruster 2013-11-01 11:15:43 UTC 
Re comment#11: JSON is just fine for such numbers, it's only the implementation in QEMU and the ideas firmly stuck in some QEMU developers' heads that aren't.  The former is fixable, the latter may not be.
Comment 17 Ademar Reis 2013-11-28 17:20:45 UTC 
(In reply to Richard W.M. Jones from comment #3)
> We obviously didn't get a very satisfactory resolution
> to this upstream.
> 
> In the meantime we have added a patch to libvirt to send
> these large numbers as negative:
> 
> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;
> h=78eb8b60d59662271c4a9a1be8c9002ee84dc8cf
> 
> If we want to go with just this, we could clone or reassign
> this bug to libvirt.  However I still think that qemu is
> *broken* here and we should push harder for a fix upstream.

Looks like this won't be changed upstream in qemu anytime soon. I'm reassigning this BZ to libvirt and marking it TestOnly.
Comment 18 dyuan 2015-01-19 11:15:15 UTC 
Installed libvirt-1.2.8-13.el7.src.rpm, check qemu_monitor_json.c.

           /* qemu silently truncates numbers larger than LLONG_MAX,
             * so passing the full range of unsigned 64 bit integers
             * is not safe here.  Pass them as signed 64 bit integers
             * instead.
             */
            long long val = va_arg(args, long long);

            if (!val && type == 'P')
                continue;

            ret = virJSONValueObjectAppendNumberLong(jargs, key, val);


Use the test program in the attachment.

# gcc -o bug706887 bug706887.c -lvirt

# ./bug706887 rhel7
success
Comment 20 errata-xmlrpc 2015-03-05 07:19:01 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/RHSA-2015-0323.html
Note You need to log in before you can comment on or make changes to this bug.