[libvirt] [PATCH] Fix off-by-1 in QEMU boot arg array handling
A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null * src/qemu/qemu_conf.c: Fix off-by-1 boot arg array size --- src/qemu/qemu_conf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index aa34d63..7a37c70 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -3662,7 +3662,7 @@ int qemudBuildCommandLine(virConnectPtr conn, { int i; char memory[50]; - char boot[VIR_DOMAIN_BOOT_LAST]; + char boot[VIR_DOMAIN_BOOT_LAST+1]; struct utsname ut; int disableKQEMU = 0; int enableKQEMU = 0; -- 1.7.2.1
On Tue, Aug 24, 2010 at 12:02:38PM +0100, Daniel P. Berrange wrote:
A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null
FYI, This bug was introduced by me 2 years ago during the conversion to common domain APIs. In 6385fe3edebf4593b6dc08eee086f73dcc71b43d. We already have a test case that covers this precise boundary condition, but it has never exhibited a problem, even under valgrind. In Fedora 15 rawhide though, there is more advanced GCC array bounds checking present and this causes a runtime abort in the test suite. Nice example of why running 'make check' in the RPM spec is good :-) Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, Aug 24, 2010 at 12:18:48PM +0100, Daniel P. Berrange wrote:
On Tue, Aug 24, 2010 at 12:02:38PM +0100, Daniel P. Berrange wrote:
A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null
FYI, This bug was introduced by me 2 years ago during the conversion to common domain APIs. In 6385fe3edebf4593b6dc08eee086f73dcc71b43d. We already have a test case that covers this precise boundary condition, but it has never exhibited a problem, even under valgrind. In Fedora 15 rawhide though, there is more advanced GCC array bounds checking present and this causes a runtime abort in the test suite. Nice example of why running 'make check' in the RPM spec is good :-)
There used to be a 'checker' version of gcc with specific patches for bound-checking a decade or so ago, good to see this coming to the main stream :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 08/24/2010 05:02 AM, Daniel P. Berrange wrote:
A QEMU guest can have upto VIR_DOMAIN_BOOT_LAST boot entries defined. When building the QEMU arg, each entry takes a single byte. This means the array must be declared to be VIR_DOMAIN_BOOT_LAST+1 bytes in length to allow for the trailing null
* src/qemu/qemu_conf.c: Fix off-by-1 boot arg array size
ACK. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake