Xen Logic Error in compat_iret() Lets Local Guest Users Deny Service on the Host System
SecurityTracker Alert ID: 1032569|
SecurityTracker URL: http://securitytracker.com/id/1032569
(Links to External Site)
Date: Jun 12 2015
Denial of service via local system|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 3.1 and later|
A vulnerability was reported in Xen. A local user on the guest system can cause denial of service conditions on the target host system.|
A local user on a 32-bit PV guest system can invoke the compat_iret() function to cause a large number of page faults and cause the target host system to hang.
64-bit x86 builds are affected.
32-bit x86 builds are not affected.
ARM systems are not affected.
Andrew Cooper of Citrix reported this vulnerability.
A local user on the guest system can cause denial of service conditions on the target host system.|
The vendor has issued a fix (xsa136*.patch).|
The vendor's advisory is available at:
Vendor URL: xenbits.xen.org/xsa/advisory-136.html (Links to External Site)
|Underlying OS: Linux (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: [oss-security] Xen Security Advisory 136 (CVE-2015-4164) - vulnerability in the iret hypercall handler|
Content-Type: text/plain; charset="utf-8"
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-4164 / XSA-136
vulnerability in the iret hypercall handler
UPDATES IN VERSION 3
Added email header syntax to patches, for e.g. git-am.
A buggy loop in Xen's compat_iret() function iterates the wrong way
around a 32-bit index. Any 32-bit PV guest kernel can trigger this
vulnerability by attempting a hypercall_iret with EFLAGS.VM set.
Given the use of __get/put_user(), and that the virtual addresses in
question are contained within the lower canonical half, the guest
cannot clobber any hypervisor data. Instead, Xen will take up to 2^33
pagefaults, in sequence, effectively hanging the host.
Malicious guest administrators can cause a denial of service affecting
the whole system.
Only 64-bit x86 (ARCH=x86_64) builds of Xen are vulnerable. 32-bit
builds (ARCH=x86_32) (necessarily of Xen 4.2 or earlier), are not
Xen versions 3.1 or later are vulnerable.
ARM systems are not vulnerable.
Only 32-bit PV guests can exploit the vulnerability.
Systems which only need to run 32-bit guests and are running Xen 4.2
or earlier can avoid the vulnerability by using a 32-bit build of Xen
instead of a 64-bit build. (The dom0 operating system would have to
be 32-bit too.)
If the boot process and kernel for the guest can be controlled,
forcing it to use a 64-bit kernel will avoid the vulnerability.
This issue was discovered by Andrew Cooper of Citrix.
Applying the attached patch resolves this issue.
$ sha256sum xsa136*.patch
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
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
(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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Content-Type: application/octet-stream; name="xsa136.patch"
Content-Disposition: attachment; filename="xsa136.patch"