From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Dov Murik <dovmurik@linux.ibm.com>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"James Bottomley" <jejb@linux.ibm.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Tobin Feldman-Fitzthum" <tobin@linux.ibm.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v2] hw/i386: Improve bounds checking in OVMF table parsing
Date: Mon, 21 Feb 2022 19:44:58 +0000 [thread overview]
Message-ID: <YhPrug59i7U0BUao@work-vm> (raw)
In-Reply-To: <20220216064024.153423-1-dovmurik@linux.ibm.com>
* Dov Murik (dovmurik@linux.ibm.com) wrote:
> When pc_system_parse_ovmf_flash() parses the optional GUIDed table in
> the end of the OVMF flash memory area, the table length field is checked
> for sizes that are too small, but doesn't error on sizes that are too
> big (bigger than the flash content itself).
>
> Add a check for maximal size of the OVMF table, and add an error report
> in case the size is invalid. In such a case, an error like this will be
> displayed during launch:
>
> qemu-system-x86_64: OVMF table has invalid size 4047
>
> and the table parsing is skipped.
>
> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
>
> ---
>
> v2:
> - add error message example to commit description
> - replace magic numbers 48 and 50 with size calculations (thanks Phil MD)
> ---
> hw/i386/pc_sysfw_ovmf.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/hw/i386/pc_sysfw_ovmf.c b/hw/i386/pc_sysfw_ovmf.c
> index f4dd92c588..1c9a16e9e6 100644
> --- a/hw/i386/pc_sysfw_ovmf.c
> +++ b/hw/i386/pc_sysfw_ovmf.c
> @@ -24,11 +24,14 @@
> */
>
> #include "qemu/osdep.h"
> +#include "qemu/error-report.h"
> #include "hw/i386/pc.h"
> #include "cpu.h"
>
> #define OVMF_TABLE_FOOTER_GUID "96b582de-1fb2-45f7-baea-a366c55a082d"
>
> +static const int bytes_after_table_footer = 32;
> +
> static bool ovmf_flash_parsed;
> static uint8_t *ovmf_table;
> static int ovmf_table_len;
> @@ -38,6 +41,8 @@ void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size)
> uint8_t *ptr;
> QemuUUID guid;
> int tot_len;
> + int max_tot_len = flash_size - (bytes_after_table_footer +
> + sizeof(guid) + sizeof(uint16_t));
>
> /* should only be called once */
> if (ovmf_flash_parsed) {
> @@ -52,12 +57,13 @@ void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size)
>
> /*
> * if this is OVMF there will be a table footer
> - * guid 48 bytes before the end of the flash file. If it's
> - * not found, silently abort the flash parsing.
> + * guid 48 bytes before the end of the flash file
> + * (= 32 bytes after the table + 16 bytes the GUID itself).
> + * If it's not found, silently abort the flash parsing.
> */
> qemu_uuid_parse(OVMF_TABLE_FOOTER_GUID, &guid);
> guid = qemu_uuid_bswap(guid); /* guids are LE */
> - ptr = flash_ptr + flash_size - 48;
> + ptr = flash_ptr + flash_size - (bytes_after_table_footer + sizeof(guid));
> if (!qemu_uuid_is_equal((QemuUUID *)ptr, &guid)) {
> return;
> }
> @@ -66,7 +72,13 @@ void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size)
> ptr -= sizeof(uint16_t);
> tot_len = le16_to_cpu(*(uint16_t *)ptr) - sizeof(guid) - sizeof(uint16_t);
Instead of the max_tot_len calculation above, is it actually:
max_tot_len = ptr - flash_ptr;
I think that works out the same and avoids doing the calculation in two
places; it's also logically what you have - you can't read over the
structure you just read.
Dave
> - if (tot_len <= 0) {
> + if (tot_len < 0 || tot_len > max_tot_len) {
> + error_report("OVMF table has invalid size %d", tot_len);
> + return;
> + }
> +
> + if (tot_len == 0) {
> + /* no entries in the OVMF table */
> return;
> }
>
>
> base-commit: 48033ad678ae2def43bf0d543a2c4c3d2a93feaf
> --
> 2.25.1
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2022-02-21 19:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 6:40 [PATCH v2] hw/i386: Improve bounds checking in OVMF table parsing Dov Murik
2022-02-21 19:44 ` Dr. David Alan Gilbert [this message]
2022-02-22 6:28 ` Dov Murik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YhPrug59i7U0BUao@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=jejb@linux.ibm.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=tobin@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.