Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 509054 (CVE-2014-3124) - <app-emulations/xen-{tools}-{4.2.4r2,4.3.2-r2},app-emulations/xen-pvgrub-{4.2.4,4.3.2): HVMOP_set_mem_type allows invalid P2M entries to be created (XSA-92) (CVE-2014-3124)
Summary: <app-emulations/xen-{tools}-{4.2.4r2,4.3.2-r2},app-emulations/xen-pvgrub-{4.2...
Alias: CVE-2014-3124
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa]
Depends on:
Reported: 2014-04-29 12:35 UTC by Agostino Sarubbo
Modified: 2014-08-10 22:11 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2014-04-29 12:35:52 UTC
From ${URL} :

                    Xen Security Advisory XSA-92
                              version 2

      HVMOP_set_mem_type allows invalid P2M entries to be created


Public release.


The implementation in Xen of the HVMOP_set_mem_type HVM control
operations attempts to exclude transitioning a page from an
inappropriate memory type.  However, only an inadequate subset of
memory types is excluded.

There are certain other types that don't correspond to a particular
valid page, whose page table translation can be inappropriately
changed (by HVMOP_set_mem_type) from not-present (due to the lack of
valid memory page) to present.  If this occurs, an invalid translation
will be established.


In a configuration where device models run with limited privilege (for
example, stubdom device models), a guest attacker who successfully
finds and exploits an unfixed security flaw in qemu-dm could leverage
the other flaw into a Denial of Service affecting the whole host.

In the more general case, in more abstract terms: a malicious
administrator of a domain privileged with regard to an HVM guest can
cause Xen to crash leading to a Denial of Service.

Arbitrary code execution, and therefore privilege escalation, cannot
be entirely excluded: On a system with a RAM page present immediately
below the 52-bit address boundary, this would be possible.  However,
we are not aware of any systems with such a memory layout.


All Xen versions from 4.1 onwards are vulnerable.

The vulnerability is only exposed to service domains for HVM guests
which have privilege over the guest.  In a usual configuration that
means only device model emulators (qemu-dm).

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of

In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended.  That is the essence of this vulnerability.

However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process.  Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.

Finally, in a radically disaggregated system: where the HVM service
domain software (probably, the device model domain image) is not
always supplied by the host administrator, a malicious service domain
administrator can exercise this vulnerability.


Running only PV guests will avoid this vulnerability.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the


This issue was discovered by Jan Beulich.


Applying the appropriate attached patch resolves this issue.

xsa92.patch                 xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa92-4.2.patch             Xen 4.2.x
xsa92-4.1.patch             Xen 4.1.x

@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Yixun Lan archtester gentoo-dev 2014-05-10 00:06:52 UTC
bug fixed in versions:
xen-4.4.0-r2 xen-4.3.2-r2 xen-4.2.4-r2
xen-tools-4.4.0-r2 xen-tools-4.3.2-r2 xen-tools-4.2.4-r2


+*xen-4.4.0-r2 (09 May 2014)
+*xen-4.3.2-r2 (09 May 2014)
+*xen-4.2.4-r2 (09 May 2014)
+  09 May 2014; Yixun Lan <> -xen-4.2.4.ebuild,
+  +xen-4.2.4-r2.ebuild, -xen-4.3.2.ebuild, +xen-4.3.2-r2.ebuild,
+  -xen-4.4.0.ebuild, -xen-4.4.0-r1.ebuild, +xen-4.4.0-r2.ebuild:
+  bump security patches, bug 508510, 508424, 509054, 509176

+*xen-tools-4.4.0-r2 (09 May 2014)
+*xen-tools-4.3.2-r2 (09 May 2014)
+*xen-tools-4.2.4-r2 (09 May 2014)
+  09 May 2014; Yixun Lan <> +xen-tools-4.2.4-r2.ebuild,
+  +xen-tools-4.3.2-r2.ebuild, +xen-tools-4.4.0-r2.ebuild,
+  +files/xen-tools-4-qemu-fix-po-collision.patch:
+  1) bump security patches, bug 508510, 508424, 509054, 509176 2) fix file
+  collision with app-emulation/qemu, bug 508302 3) drop old
Comment 2 Yixun Lan archtester gentoo-dev 2014-05-16 09:06:07 UTC
Arches, please test and mark stable:
Target keywords Both : "amd64 x86"

Target keywords Only: "amd64"

after stabilization, we'll start to clean old ebuilds, thanks.
Comment 3 Agostino Sarubbo gentoo-dev 2014-05-17 13:32:42 UTC
amd64 stable
Comment 4 Agostino Sarubbo gentoo-dev 2014-05-17 13:34:13 UTC
x86 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 5 Yixun Lan archtester gentoo-dev 2014-05-17 14:20:37 UTC
tree cleaning was done, old versions were dropped, files in ${FILESDIR} were cleanup.
And all security bugs should be addressed.
Comment 6 Yury German Gentoo Infrastructure gentoo-dev 2014-05-20 03:02:27 UTC
Maintainer(s), Thank you for cleanup!

Security please Vote!
Comment 7 Yixun Lan archtester gentoo-dev 2014-05-27 22:58:41 UTC
sorry, but it seems to me that too many xen security bugs are still marked as IN_PROGRESS status.. what do we still need to do? the vote? can we just get them closed? 

many thanks
Comment 8 Yury German Gentoo Infrastructure gentoo-dev 2014-05-27 23:37:53 UTC
(In reply to Yixun Lan from comment #7)
> sorry, but it seems to me that too many xen security bugs are still marked
> as IN_PROGRESS status.. what do we still need to do? the vote? can we just
> get them closed? 
> many thanks

We need to follow the policy outlines in

Once we release the GLSA we will close the bugs.
Comment 9 Yury German Gentoo Infrastructure gentoo-dev 2014-05-27 23:43:37 UTC
Added to an existing GLSA request.
Comment 10 GLSAMaker/CVETool Bot gentoo-dev 2014-07-16 16:47:07 UTC
This issue was resolved and addressed in
 GLSA 201407-03 at
by GLSA coordinator Mikle Kolyada (Zlogene).
Comment 11 GLSAMaker/CVETool Bot gentoo-dev 2014-08-10 22:11:29 UTC
CVE-2014-3124 (
  The HVMOP_set_mem_type control in Xen 4.1 through 4.4.x allows local guest
  HVM administrators to cause a denial of service (hypervisor crash) or
  possibly execute arbitrary code by leveraging a separate qemu-dm
  vulnerability to trigger invalid page table translations for unspecified
  memory page types.