Bugzilla – Bug 956407
VUL-0: CVE-2015-8338: xen: long running memory operations on ARM (XSA-158)
Last modified: 2015-12-08 12:14:22 UTC
Xen Security Advisory CVE-2015-8338 / XSA-158
long running memory operations on ARM
UPDATES IN VERSION 3
Certain HYPERVISOR_memory_op subops take page order inputs, with so far
insufficient enforcement of limits thereof. In particular, for all of
XENMEM_increase_reservation, XENMEM_populate_physmap, and
XENMEM_exchange the order was limited to 9 only for guests without
physical devices assigned. Guests with assigned devices were allowed up
to order 18 (x86) or 20 (ARM). XENMEM_decrease_reservation enforced
only the latter, higher limit uniformly on all kinds of guests.
All of these operations involve loops over individual pages (possibly
nested, with only the iteration count of the innermost loop being of
interest here), resulting in iteration counts of up to 1 million on
ARM. Total execution time of these operations obviously depends on
system speed, but have been measured to get into the seconds range.
A malicious guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant period.
Other attacks, namely privilege escalation, cannot be ruled out.
If a host watchdog (Xen or dom0) is in use, this can lead to a
watchdog timeout and consequently a reboot of the host. If another,
innocent, guest, is configured with a watchdog, this issue can lead to
a reboot of such a guest.
All Xen versions supporting ARM are affected.
x86 versions of Xen are unaffected.
The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege. On
ARM, controlling the guest's kernel may involve locking down the
Exposure may be limited by not passing through physical devices to
(However, where device pass-through is being used to enhance security,
for example, by disaggregating device drivers, users should not change
their configuration: moving the drivers from a separate domain, to
dom0, does NOT mitigate this vulnerability. Rather, it simply
recategorises the additional exposure, regarding it "as designed" and
therefore "not a bug". Users and vendors of disaggregated systems
should not change their configuration.)
This issue was discovered by Julien Grall of Citrix.
Applying the appropriate attached patch resolves this issue.
xsa158.patch xen-unstable, Xen 4.6.x, Xen 4.5.x
xsa158-4.4.patch Xen 4.4.x, Xen 4.3.x
$ sha256sum xsa158*