All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	qemu-arm@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>
Subject: [PATCH 2/5] hw/smbios: report error if table size is too large
Date: Tue,  8 Sep 2020 17:54:35 +0100	[thread overview]
Message-ID: <20200908165438.1008942-3-berrange@redhat.com> (raw)
In-Reply-To: <20200908165438.1008942-1-berrange@redhat.com>

The SMBIOS 2.1 entry point uses a uint16 data type for reporting the
total length of the tables. If the user passes -smbios configuration to
QEMU that causes the table size to exceed this limit then various bad
behaviours result, including

 - firmware hangs in an infinite loop
 - firmware triggers a KVM crash on bad memory access
 - firmware silently discards user's SMBIOS data replacing it with
   a generic data set.

Limiting the size to 0xffff in QEMU avoids triggering most of these
problems. There is a remaining bug in SeaBIOS which tries to prepend its
own data for table 0, and does not check whether there is sufficient
space before attempting this.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 hw/smbios/smbios.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 8450fad285..3c87be6c91 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -365,6 +365,13 @@ static void smbios_register_config(void)
 
 opts_init(smbios_register_config);
 
+/*
+ * The SMBIOS 2.1 "structure table length" field in the
+ * entry point uses a 16-bit integer, so we're limited
+ * in total table size
+ */
+#define SMBIOS_21_MAX_TABLES_LEN 0xffff
+
 static void smbios_validate_table(MachineState *ms)
 {
     uint32_t expect_t4_count = smbios_legacy ?
@@ -375,6 +382,13 @@ static void smbios_validate_table(MachineState *ms)
                      expect_t4_count, smbios_type4_count);
         exit(1);
     }
+
+    if (smbios_ep_type == SMBIOS_ENTRY_POINT_21 &&
+        smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
+        error_report("SMBIOS 2.1 table length %zu exceeds %d",
+                     smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
+        exit(1);
+    }
 }
 
 
-- 
2.26.2



  parent reply	other threads:[~2020-09-08 16:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 16:54 [PATCH 0/5] Add support for loading SMBIOS OEM strings from a file Daniel P. Berrangé
2020-09-08 16:54 ` [PATCH 1/5] hw/smbios: support loading OEM strings values " Daniel P. Berrangé
2020-09-08 18:24   ` Philippe Mathieu-Daudé
2020-09-09  7:35     ` Daniel P. Berrangé
2020-09-09  8:33       ` Philippe Mathieu-Daudé
2020-09-09  8:18   ` Laszlo Ersek
2020-09-09  9:00     ` Daniel P. Berrangé
2020-09-09  9:10     ` Daniel P. Berrangé
2020-09-09  8:24   ` Laszlo Ersek
2020-09-08 16:54 ` Daniel P. Berrangé [this message]
2020-09-08 18:25   ` [PATCH 2/5] hw/smbios: report error if table size is too large Philippe Mathieu-Daudé
2020-09-14  8:02   ` Igor Mammedov
2020-09-08 16:54 ` [PATCH 3/5] qemu-options: document SMBIOS type 11 settings Daniel P. Berrangé
2020-09-08 18:27   ` Philippe Mathieu-Daudé
2020-09-08 16:54 ` [PATCH 4/5] hw/smbios: use qapi for SMBIOS entry point type enum Daniel P. Berrangé
2020-09-08 18:29   ` Philippe Mathieu-Daudé
2020-09-09  7:36     ` Daniel P. Berrangé
2020-09-08 18:37   ` Philippe Mathieu-Daudé
2020-12-09 17:56   ` Eduardo Habkost
2020-09-08 16:54 ` [PATCH 5/5] hw/i386: expose a "smbios_ep" PC machine property Daniel P. Berrangé
2020-09-08 18:38   ` Philippe Mathieu-Daudé
2020-09-09  8:28   ` Laszlo Ersek
2020-09-09  9:44 ` [PATCH 0/5] Add support for loading SMBIOS OEM strings from a file Laszlo Ersek
2020-09-09  9:50   ` Daniel P. Berrangé
2020-09-09 10:58     ` Laszlo Ersek

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=20200908165438.1008942-3-berrange@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.