linux-kernel - [PATCH 3.10 039/319] xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1486322486-8024-10-git-send-email-w@1wt.eu>
Date:   Sun,  5 Feb 2017 20:20:26 +0100
From:   Willy Tarreau <w@....eu>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        linux@...ck-us.net
Cc:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Willy Tarreau <w@....eu>
Subject: [PATCH 3.10 039/319] xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled

From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>

commit 5e0ce1455c09dd61d029b8ad45d82e1ac0b6c4c9 upstream.

The guest sequence of:

  a) XEN_PCI_OP_enable_msix
  b) XEN_PCI_OP_enable_msix

results in hitting an NULL pointer due to using freed pointers.

The device passed in the guest MUST have MSI-X capability.

The a) constructs and SysFS representation of MSI and MSI groups.
The b) adds a second set of them but adding in to SysFS fails (duplicate entry).
'populate_msi_sysfs' frees the newly allocated msi_irq_groups (note that
in a) pdev->msi_irq_groups is still set) and also free's ALL of the
MSI-X entries of the device (the ones allocated in step a) and b)).

The unwind code: 'free_msi_irqs' deletes all the entries and tries to
delete the pdev->msi_irq_groups (which hasn't been set to NULL).
However the pointers in the SysFS are already freed and we hit an
NULL pointer further on when 'strlen' is attempted on a freed pointer.

The patch adds a simple check in the XEN_PCI_OP_enable_msix to guard
against that. The check for msi_enabled is not stricly neccessary.

This is part of XSA-157

Reviewed-by: David Vrabel <david.vrabel@...rix.com>
Reviewed-by: Jan Beulich <jbeulich@...e.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Signed-off-by: Willy Tarreau <w@....eu>
---
 drivers/xen/xen-pciback/pciback_ops.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
index 0dadc2a..1765509 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -203,9 +203,16 @@ int xen_pcibk_enable_msix(struct xen_pcibk_device *pdev,
 	if (unlikely(verbose_request))
 		printk(KERN_DEBUG DRV_NAME ": %s: enable MSI-X\n",
 		       pci_name(dev));
+
 	if (op->value > SH_INFO_MAX_VEC)
 		return -EINVAL;

+	if (dev->msix_enabled)
+		return -EALREADY;
+
+	if (dev->msi_enabled)
+		return -ENXIO;
+
 	entries = kmalloc(op->value * sizeof(*entries), GFP_KERNEL);
 	if (entries == NULL)
 		return -ENOMEM;
-- 
2.8.0.rc2.1.gbe9624a