Certain actions require removing pages from a guest's P2M
(Physical-to-Machine) mapping. When large pages are in use to map
guest pages in the 2nd-stage page tables, such a removal operation may
incur a memory allocation (to replace a large mapping with individual
smaller ones). If this allocation fails, these errors are ignored by
the callers, which would then continue and (for example) free the
referenced page for reuse. This leaves the guest with a mapping to a
page it shouldn't have access to.
The allocation involved comes from a separate pool of memory created
when the domain is created; under normal operating conditions it never
fails, but a malicious guest may be able to engineer situations where
this pool is exhausted.
A malicious guest may be able to access memory it doesn't own,
potentially allowing privilege escalation, host crashes, or
Xen versions from at least 3.2 onwards are vulnerable. Older versions
have not been inspected.
Both x86 and ARM systems are vulnerable.
On x86 systems, only HVM guests can leverage the vulnerability.
On x86, specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command
line will avoid the vulnerability.
Alternatively, running all x86 HVM guests in shadow mode will also
avoid this vulnerability. (For example, by specifying "hap=0" in the
xl domain configuration file.)
There is no known mitigation on ARM systems.
This issue was discovered by Julien Grall of ARM.
Applying the appropriate pair of attached patches resolves this issue.
xsa222-1.patch, xsa222-2-4.8.patch Xen 4.8.x
xsa222--4.7.patch Xen 4.7.x
xsa222--4.6.patch Xen 4.6.x
xsa222-1-4.6.patch, xsa222-2-4.5.patch Xen 4.5.x
$ sha256sum xsa222*
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.)
Author: Yixun Lan <firstname.lastname@example.org>
Date: Wed Jul 12 15:15:52 2017 +0800
app-emulation/xen: security bump
Package-Manager: Portage-2.3.6, Repoman-2.3.2
:100644 100644 6534404116c... 49df2654a33... M app-emulation/xen/Manifest
:000000 100644 00000000000... f66bd1b70f8... A app-emulation/xen/xen-4.7.3.ebuild
:000000 100644 00000000000... bf73951bc39... A app-emulation/xen/xen-4.8.1-r2.ebuild
Thank you Yixun Lan
Arches please let us know when all is stable
Added to an existing GLSA Request.
Maintainer(s), please drop the vulnerable version(s).
x86 never went stable.
@x86 please stabilize.
x86 does not stable app-emulation/xen
This issue was resolved and addressed in
GLSA 201710-17 at https://security.gentoo.org/glsa/201710-17
by GLSA coordinator Aaron Bauman (b-man).