opts: don't silently truncate long option values
commit950c4e6c94b15cd0d8b63891dddd7a8dbf458e6a
authorDaniel P. Berrangé <berrange@redhat.com>
Mon, 16 Apr 2018 11:17:43 +0000 (16 12:17 +0100)
committerPaolo Bonzini <pbonzini@redhat.com>
Tue, 8 May 2018 22:13:39 +0000 (9 00:13 +0200)
tree2bdd924ae43f9863fe4a15accbddd155a189e56e
parente652714f98f22e8882e88e3d563b025c5b00feec
opts: don't silently truncate long option values

The existing QemuOpts parsing code uses a fixed size 1024 byte buffer
for storing the option values. If a value exceeded this size it was
silently truncated and no error reported to the user. Long option values
is not a common scenario, but it is conceivable that they will happen.
eg if the user has a very deeply nested filesystem it would be possible
to come up with a disk path that was > 1024 bytes. Most of the time if
such data was silently truncated, the user would get an error about
opening a non-existant disk. If they're unlucky though, QEMU might use a
completely different disk image from another VM, which could be
considered a security issue. Another example program was in using the
-smbios command line arg with very large data blobs. In this case the
silent truncation will be providing semantically incorrect data to the
guest OS for SMBIOS tables.

If the operating system didn't limit the user's argv when spawning QEMU,
the code should honour whatever length arguments were given without
imposing its own length restrictions. This patch thus changes the code
to use a heap allocated buffer for storing the values during parsing,
lifting the arbitrary length restriction.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180416111743.8473-4-berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
hw/i386/multiboot.c
include/qemu/option.h
util/qemu-option.c