[kernel-xen] Xen Security Advisory 134 (CVE-2015-4163) - GNTTABOP_swap_grant_ref operation misbehavior

[Steven Haigh]

            Xen Security Advisory CVE-2015-4163 / XSA-134
                              version 3

             GNTTABOP_swap_grant_ref operation misbehavior

UPDATES IN VERSION 3
====================

Public release.

Added email header syntax to patches, for e.g. git-am.

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

With the introduction of version 2 grant table operations, a version
check became necessary for most grant table related hypercalls.  The
GNTTABOP_swap_grant_ref call was lacking such a check.  As a result,
the subsequent code behaved as if version 2 was in use, when a guest
issued this hypercall without a prior GNTTABOP_setup_table or
GNTTABOP_set_version.

The effect is a possible NULL pointer dereferences.  However, this
cannot be exploited to elevate privileges of the attacking domain, as
the maximum memory address that can be wrongly accessed this way is
bounded to far below the start of hypervisor memory.

IMPACT
======

Malicious or buggy guest domain kernels can mount a denial of service
attack which, if successful, can affect the whole system.

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

Xen versions from 4.2 onwards are vulnerable.

MITIGATION
==========

There is no mitigation available.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

* Thu Jun 11 2015 Steven Haigh <netwiz at crc.id.au> - 4.2.5-18
- XSA-134 (CVE-2015-4163) GNTTABOP_swap_grant_ref operation misbehavior
- XSA-136 (CVE-2015-4164) vulnerability in the iret hypercall handler

Thu Jun 11 2015 Steven Haigh <netwiz at crc.id.au> - 4.4.1-18
- XSA-134 (CVE-2015-4163) GNTTABOP_swap_grant_ref operation misbehavior
- XSA-136 (CVE-2015-4164) vulnerability in the iret hypercall handler

Thu Jun 11 2015 Steven Haigh <netwiz at crc.id.au> - 4.5.0-0.13
- XSA-134 (CVE-2015-4163) GNTTABOP_swap_grant_ref operation misbehavior
- XSA-136 (CVE-2015-4164) vulnerability in the iret hypercall handler

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.wireless.org.au/pipermail/kernel-xen/attachments/20150611/269028d9/attachment.sig>