Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Have attached patches for two security issues in the wheezy version.

CVE-2015-2752.diff
CVE-2015-8104+CVE-2015-5307.patch

Not tested in anyway, except they apply ok.

Am currently looking at CVE-2015-7969; I am beginning to think wheezy is
not vulnerable. Still need to double check this.

Out of time now, will continue looking at this later.
-- 
Brian May 
>From 16794c97e99228ca551ff09fa696d00f39ceee82 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 19 Nov 2014 12:57:11 -0500
Subject: Limit XEN_DOMCTL_memory_mapping hypercall to only process up to 64
 GFNs (or less)

Said hypercall for large BARs can take quite a while. As such
we can require that the hypercall MUST break up the request
in smaller values.

Another approach is to add preemption to it - whether we do the
preemption using hypercall_create_continuation or returning
EAGAIN to userspace (and have it re-invocate the call) - either
way the issue we cannot easily solve is that in 'map_mmio_regions'
if we encounter an error we MUST call 'unmap_mmio_regions' for the
whole BAR region.

Since the preemption would re-use input fields such as nr_mfns,
first_gfn, first_mfn - we would lose the original values -
and only undo what was done in the current round (i.e. ignoring
anything that was done prior to earlier preemptions).

Unless we re-used the return value as 'EAGAIN|nr_mfns_done<<10' but
that puts a limit (since the return value is a long) on the amount
of nr_mfns that can provided.

This patch sidesteps this problem by:
 - Setting an hard limit of nr_mfns having to be 64 or less.
 - Toolstack adjusts correspondingly to the nr_mfn limit.
 - If the there is an error when adding the toolstack will call the
   remove operation to remove the whole region.

The need to break this hypercall down is for large BARs can take
more than the guest (initial domain usually) time-slice. This has
the negative result in that the guest is locked out for a long
duration and is unable to act on any pending events.

We also augment the code to return zero if nr_mfns instead
of trying to the hypercall.

This is XSA-125 / CVE-2015-2752.

Suggested-by: Jan Beulich 
Acked-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Ian Campbell 
(cherry picked from commit 518ae14973a44228fd7158c3d70270df6ed90033)

Patch-Name: CVE-2015-2752.diff
---
 tools/libxc/xc_domain.c | 55 -
 xen/arch/x86/domctl.c   |  5 +
 xen/include/public/domctl.h |  1 +
 3 files changed, 56 insertions(+), 5 deletions(-)

--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1322,6 +1322,13 @@
   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+#ifndef min
+#define min(X, Y) ({ \
+const typeof (X) _x = (X);   \
+const typeof (Y) _y = (Y);   \
+(void) (&_x == &_y); \
+(_x < _y) ? _x : _y; })
+#endif
 int xc_domain_memory_mapping(
 xc_interface *xch,
 uint32_t domid,
@@ -1331,17 +1338,55 @@
 uint32_t add_mapping)
 {
 DECLARE_DOMCTL;
+int ret = 0, err;
+unsigned long done = 0, nr, max_batch_sz;
+
+if ( !nr_mfns )
+return 0;
 
 domctl.cmd = XEN_DOMCTL_memory_mapping;
 domctl.domain = domid;
-domctl.u.memory_mapping.first_gfn = first_gfn;
-domctl.u.memory_mapping.first_mfn = first_mfn;
-domctl.u.memory_mapping.nr_mfns = nr_mfns;
 domctl.u.memory_mapping.add_mapping = add_mapping;
+max_batch_sz = nr_mfns;
+do
+{
+nr = min(nr_mfns - done, max_batch_sz);
+domctl.u.memory_mapping.nr_mfns = nr;
+domctl.u.memory_mapping.first_gfn = first_gfn + done;
+domctl.u.memory_mapping.first_mfn = first_mfn + done;
+err = do_domctl(xch, );
+if ( err && errno == E2BIG )
+{
+if ( max_batch_sz <= 1 )
+break;
+max_batch_sz >>= 1;
+continue;
+}
+/* Save the first error... */
+if ( !ret )
+ret = err;
+/* .. and ignore the rest of them when removing. */
+if ( err && add_mapping != DPCI_REMOVE_MAPPING )
+break;
 
-return do_domctl(xch, );
-}
+done += nr;
+} while ( done < nr_mfns );
+
+/*
+ * Undo what we have done unless unmapping, by unmapping the entire region.
+ * Errors here are ignored.
+ */
+if ( ret && add_mapping != DPCI_REMOVE_MAPPING )
+xc_domain_memory_mapping(xch, domid, first_gfn, first_mfn, nr_mfns,
+ DPCI_REMOVE_MAPPING);
 
+/* We might get E2BIG so many times that we never advance. */
+if ( !done && !ret )
+ret = -1;
+
+return ret;
+}
+#undef min
 int xc_domain_ioport_mapping(
 xc_interface *xch,
 uint32_t domid,
--- 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Guido Günther  writes:>

> Sid has Xen 4.6 and looking at the CVEs that affect sid the patches
> don't seem to be applied so the tracker looks correct, there's plenty of
> work left.
>
> Are you going to look at the Wheezy packages?

Looking now.

Just looking at CVE-2015-2756 - this appears to be a vulnerability in
qemu - not xen - and squeeze and wheezy are not affected.

https://security-tracker.debian.org/tracker/CVE-2015-2756

Looking at xen in jessie, there is no changelog entry mentioning
CVE-2015-2756; although it is marked as fixed.

The closest I can find is https://bugs.debian.org/781620 and this
doesn't mention how CVE-2015-2756 was fixed.

The only reason xen appears to be mentioned is because it can use a
vulnerable version of qemu; It doesn't appear to have the vulnerable
code itself.

See: http://xenbits.xen.org/xsa/advisory-126.html

So I am wondering if I can just mark xen in squeeze and wheezy as not
being affected by CVE-2015-2756 too?
-- 
Brian May