Bug 1272519 - (CVE-2015-7969, xsa149, xsa151) CVE-2015-7969 xen: leak of main per-domain vcpu pointer array
CVE-2015-7969 xen: leak of main per-domain vcpu pointer array
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20151029,repor...
: Security
: 1272522 (view as bug list)
Depends On: 1276344
Blocks: 1272534
  Show dependency treegraph
 
Reported: 2015-10-16 11:46 EDT by Adam Mariš
Modified: 2016-03-09 09:45 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Upstream patch (510 bytes, patch)
2015-10-16 11:47 EDT, Adam Mariš
no flags Details | Diff

  None (edit)
Description Adam Mariš 2015-10-16 11:46:08 EDT
A domain's primary array of vcpu pointers can be allocated by a toolstack exactly once in the lifetime of a domain via the XEN_DOMCTL_max_vcpus hypercall. This array is leaked on domain teardown. This memory leak could over time exhaust the host's memory.

A domain given partial management control via XEN_DOMCTL_max_vcpus can mount a denial of service attack affecting the whole system. The ability to also restart or create suitable domains is also required to fully exploit the issue. Without this the leak is limited to a small multiple of the maximum number of vcpus for the domain. The maximum leak is 64kbytes per domain (re)boot (less on ARM).

This issue is only relevant to systems which intend to increase security through the use of advanced disaggregated management techniques. This does not include systems using libxl, libvirt, or OpenStack (unless substantially modified or supplemented, as compared to versions supplied by the respective upstreams). Versions of Xen from 4.0 onwards are vulnerable. All architectures are affected.

Mitigation:

The leak is small. Preventing the creation of large numbers of new domains, and limiting the number of times an existing domain can be rebooted, can reduce the impact of this vulnerability. Switching from disaggregated to a non-disaggregated operation does NOT mitigate the XEN_DOMCTL_max_vcpus vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". Users and vendors of disaggregated systems should not change their configuration.
Comment 1 Adam Mariš 2015-10-16 11:47 EDT
Created attachment 1083748 [details]
Upstream patch
Comment 3 Martin Prpič 2015-10-29 09:46:47 EDT
*** Bug 1272522 has been marked as a duplicate of this bug. ***
Comment 4 Martin Prpič 2015-10-29 09:48:12 EDT
This CVE also covers the same issue in XSA 151:

ISSUE DESCRIPTION
=================

A domain's xenoprofile state contains an array of per-vcpu
information, which is allocated once in the lifetime of a domain in
response to that domain using the XENOPROF_get_buffer hypercall on
itself or by a domain with the privilege to profile a target domain
using the XENOPROF_set_passive hypercall.

This array is leaked on domain teardown.  This memory leak could --
over time -- exhaust the host's memory.

IMPACT
======

The following parties can mount a denial of service attack affecting
the whole system:

  - A malicious guest administrator via XENOPROF_get_buffer.
  - A domain given suitable privilege over another domain
    via XENOPROF_set_passive (this would usually be a domain being
    used to profile another domain, eg with the xenoprof tool).

The ability to also restart or create suitable domains is also
required to fully exploit the issue.  Without this the leak is limited
to a small multiple of the maximum number of vcpus for the domain.

The maximum leak is 128kbytes per domain (re)boot.

VULNERABLE SYSTEMS
==================

Versions of Xen from 4.0 onwards are vulnerable.

The XENOPROF hypercalls are only implemented on x86.  ARM is therefore
not vulnerable.

MITIGATION
==========

On systems where the guest kernel is controlled by the host rather
than guest administrator, running only kernels (in the target and
profiling domain respectively) which do not call these hypercalls will
also prevent untrusted guest users from exploiting this issue. However
untrusted guest administrators can still trigger it unless further
steps are taken to prevent them 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.

The leak is small.  Preventing the creation of large numbers of new
domains, and limiting the number of times an existing domain can be
rebooted, can reduce the impact of this vulnerability.

NOTE REGARDING CVE
==================

Note that CVE-2015-7969 covers both this issue and XSA-149.
Comment 5 Martin Prpič 2015-10-29 09:51:02 EDT
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1276344]
Comment 6 Fedora Update System 2015-11-08 17:20:38 EST
xen-4.5.1-14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2015-11-09 19:21:53 EST
xen-4.5.1-14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2015-11-09 19:50:02 EST
xen-4.4.3-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.