From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
Alistair Popple <alistair@popple.id.au>
Subject: [PATCH kernel] vfio_pci: Make extended capabilities test more robust
Date: Thu, 28 Apr 2016 21:04:52 +1000 [thread overview]
Message-ID: <1461841492-29277-1-git-send-email-aik@ozlabs.ru> (raw)
VFIO reads a dword beyond the standard PCI config space (256 bytes) to
know if there are extended config space (4096 bytes). It relies on
the platform to return zero if there is no extended space.
However at least on PPC64/POWERNV platform, the system firmware (OPAL)
returns 0xffffffff in this case. VFIO treats it as a proof that there is
extended config space and calls vfio_ecap_init() which fails to parse
capabilities (which is expected) but right before the exit, it writes
zero at offset of 256 which is beyond the buffer allocated for
vdev->vconfig - it is 256 bytes for a device without extended config
space.
This adds an additional check that config space read returned non-zero
and non-ffffffff value.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
drivers/vfio/pci/vfio_pci_config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
index 142c533..8a53421 100644
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -1140,7 +1140,7 @@ static int vfio_cap_len(struct vfio_pci_device *vdev, u8 cap, u8 pos)
case PCI_CAP_ID_EXP:
/* Test for extended capabilities */
pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword);
- vdev->extended_caps = (dword != 0);
+ vdev->extended_caps = (dword != 0) && (dword != 0xffffffff);
/* length based on version */
if ((pcie_caps_reg(pdev) & PCI_EXP_FLAGS_VERS) == 1)
--
2.5.0.rc3
next reply other threads:[~2016-04-28 11:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 11:04 Alexey Kardashevskiy [this message]
2016-04-28 16:57 ` [PATCH kernel] vfio_pci: Make extended capabilities test more robust Alex Williamson
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=1461841492-29277-1-git-send-email-aik@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=alistair@popple.id.au \
--cc=benh@kernel.crashing.org \
--cc=gwshan@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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