-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2018-7541 / XSA-255
grant table v2 -> v1 transition may crash Xen
UPDATES IN VERSION 4
Grant tables come in two flavors (versions), and domains are permitted
to freely change between them (subject to certain constraints). For
the guest to use the facility, both the "normal" shared pages
(applicable to v1 and v2) and the "status" pages (applicable to v2
only) need to be mapped by the guest into its address space.
When transitioning from v2 to v1, the status pages become unnecessary
and are therefore freed by Xen. That means Xen needs to check that
there are no mappings of those pages by the domain. However, that
check was mistakenly implemented as a bug check, rather than returning
an error to the guest.
A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host. Privilege
escalation as well as information leaks cannot be ruled out for HVM,
PVH (both x86), and ARM guests.
The impact is more severe for Xen versions 4.0.x, 4.1.0 ... 4.1.3, and
4.2 in that the pages are freed without any checking, thus allowing
their re-use for another domain, or by Xen itself, while there still
are active mappings (see XSA-26).
Xen versions 4.0 and newer are vulnerable.
Both x86 and ARM systems are vulnerable.
Using the "gnttab=max_ver:1" hypervisor command line option, where
available, to disable use of v2 grant tables allows to avoid the
vulnerability. Use of this option will, however, break any guests which
require to make use of v2 functionality. The patch introducing this
option was not merged so far, but is available (in its current form) at
("common/gnttab: Introduce command line feature controls").
There is no other known mitigation.
This issue was discovered by Jan Beulich of SUSE.
Applying the appropriate attached patch resolves this issue.
xsa255-?.patch xen-unstable, Xen 4.10.x
xsa255-4.9-?.patch Xen 4.9.x, Xen 4.8.x
xsa255-4.7-?.patch Xen 4.7.x
xsa255-4.6-?.patch Xen 4.6.x
$ sha256sum xsa255*
DEPLOYMENT DURING EMBARGO
Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
However, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List). Specifically, deployment on public cloud systems
is NOT permitted. This is because this produces a guest-visible
change which will indicate which component contains the vulnerability.
Additionally, 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
-----END PGP SIGNATURE-----
Xen-users mailing list
xsa255-1.patch (8K) Download Attachment
xsa255-2.patch (8K) Download Attachment
xsa255-4.6-1.patch (5K) Download Attachment
xsa255-4.6-2.patch (9K) Download Attachment
xsa255-4.7-1.patch (5K) Download Attachment
xsa255-4.7-2.patch (9K) Download Attachment
xsa255-4.9-1.patch (5K) Download Attachment
xsa255-4.9-2.patch (9K) Download Attachment
|Free forum by Nabble||Edit this page|