Xen IRQ Setup Use-After-Free Lets Local Guest Users Gain Elevated Privileges on the Host System
SecurityTracker Alert ID: 1029679|
SecurityTracker URL: http://securitytracker.com/id/1029679
(Links to External Site)
Date: Jan 23 2014
Execution of arbitrary code via local system, User access via local system|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 4.2.x, 4.3.x|
A vulnerability was reported in Xen. A local user on the guest system can obtain elevated privileges on the target host system.|
A local administrative user on the guest system can trigger a flaw when setting up the IRQ for a passed-through physical device to cause a use-after-free memory error and potentially execute arbitrary code on the hypervisor.
Only systems using device passthrough are affected.
Only systems with a 64-bit hypervisor configured to support more than 128 CPUs or with a 32-bit hypervisor configured to support more than 64 CPUs are affected.
The vulnerability was detected using Coverity Scan.
A local user on the guest system can obtain elevated privileges on the target host system.|
The vendor has issued a fix (xsa83.patch).|
Vendor URL: www.xen.org/ (Links to External Site)
Access control error|
Source Message Contents
Date: Thu, 23 Jan 2014 14:27:20 +0000|
Subject: [oss-security] Xen Security Advisory 83 (CVE-2014-1642) - Out-of-memory condition yielding memory corruption during IRQ setup
Content-Type: text/plain; charset="utf-8"
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2014-1642 / XSA-83
Out-of-memory condition yielding memory corruption during IRQ setup
UPDATES IN VERSION 3
When setting up the IRQ for a passed through physical device, a flaw
in the error handling could result in a memory allocation being used
after it is freed, and then freed a second time. This would typically
result in memory corruption.
Malicious guest administrators can trigger a use-after-free error, resulting
in hypervisor memory corruption. The effects of memory corruption could be
anything, including a host-wide denial of service, or privilege escalation.
Xen 4.2.x and later are vulnerable.
Xen 4.1.x and earlier are not vulnerable.
Only systems making use of device passthrough are vulnerable.
Only systems with a 64-bit hypervisor configured to support more than 128
CPUs or with a 32-bit hypervisor configured to support more than 64 CPUs are
This issue can be avoided by not assigning PCI devices to untrusted guests on
systems supporting Intel VT-d or AMD Vi.
This issue was discovered by Coverity Scan, prompted by modelling
improvements contributed by Andrew Coooper. The issue was diagnosed
by Matthew Daley and Andrew Coooper. The patch was prepared by Andrew
Applying the attached patch resolves this issue.
xsa83.patch Xen 4.2.x, Xen 4.3.x, xen-unstable
$ sha256sum xsa83*.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Content-Type: application/octet-stream; name="xsa83.patch"
Content-Disposition: attachment; filename="xsa83.patch"