From: David Gibson <david@gibson.dropbear.id.au>
To: anthony@codemonkey.ws
Cc: agraf@suse.de, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH 3/4] pci: Make bounds checks on config space accesses actually work
Date: Wed, 11 Jan 2012 16:44:51 +1100 [thread overview]
Message-ID: <1326260692-7272-4-git-send-email-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <1326260692-7272-1-git-send-email-david@gibson.dropbear.id.au>
The pci_host_config_{read,write}_common() functions perform PCI config
accesses. They take a limit parameter which they appear to be supposed
to bounds check against, however the bounds checking logic, such as it is,
is completely broken.
Currently, it takes the minimum of the supplied length and the remaining
space in the region and passes that as the length to the underlying
config_{read,write} function pointer. This means that accesses which
partially overrun the region will be silently truncated - which makes
little sense. Accesses which entirely overrun the region will *not*
be blocked (an exploitable bug), because in that case (limit - addr) will
be negative and so the unsigned MIN will always return len instead. Even
if signed arithmetic was used, the config_{read,write} callback wouldn't
know what to do with a negative len parameter.
This patch handles things more sanely by simply ignoring writes which
overrun, and returning -1 for reads, which is the usual hardware convention
for reads to unpopulated IO regions.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
hw/pci_host.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/pci_host.c b/hw/pci_host.c
index 44c6c20..16b3ac3 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -51,14 +51,20 @@ void pci_host_config_write_common(PCIDevice *pci_dev, uint32_t addr,
uint32_t limit, uint32_t val, uint32_t len)
{
assert(len <= 4);
- pci_dev->config_write(pci_dev, addr, val, MIN(len, limit - addr));
+ if ((addr + len) <= limit) {
+ pci_dev->config_write(pci_dev, addr, val, len);
+ }
}
uint32_t pci_host_config_read_common(PCIDevice *pci_dev, uint32_t addr,
uint32_t limit, uint32_t len)
{
assert(len <= 4);
- return pci_dev->config_read(pci_dev, addr, MIN(len, limit - addr));
+ if ((addr + len) <= limit) {
+ return pci_dev->config_read(pci_dev, addr, len);
+ } else {
+ return ~0x0;
+ }
}
void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len)
--
1.7.7.3
next prev parent reply other threads:[~2012-01-11 5:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 5:44 [Qemu-devel] [0/4] Assorted bugfixes David Gibson
2012-01-11 5:44 ` [Qemu-devel] [PATCH 1/4] load_image_targphys() should enforce the max size David Gibson
2012-01-11 6:19 ` Stefan Weil
2012-01-12 3:26 ` David Gibson
2012-01-11 5:44 ` [Qemu-devel] [PATCH 2/4] Fix dirty logging with 32-bit qemu & 64-bit guests David Gibson
2012-01-11 5:44 ` David Gibson [this message]
2012-01-11 6:25 ` [Qemu-devel] [PATCH 3/4] pci: Make bounds checks on config space accesses actually work Stefan Weil
2012-01-12 3:27 ` David Gibson
2012-01-12 6:10 ` Stefan Weil
2012-01-11 5:44 ` [Qemu-devel] [PATCH 4/4] Update gitignore file David Gibson
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=1326260692-7272-4-git-send-email-david@gibson.dropbear.id.au \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).