-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory XSA-247
Missing p2m error checking in PoD code
UPDATES IN VERSION 2
Certain actions require modification of entries in a guest's P2M
(Physical-to-Machine) table. When large pages are in use for this
table, such an operation may incur a memory allocation (to replace a
large mapping with individual smaller ones). If this allocation
fails, the p2m_set_entry() function will return an error.
Unfortunately, several places in the populate-on-demand code don't
check the return value of p2m_set_entry() to see if it succeeded.
In some cases, the operation was meant to remove an entry from the p2m
table. If this removal fails, a malicious guest may engineer that the
page be returned to the Xen free list, making it available to be
allocated to another domain, while it retains a writable mapping to
In other cases, the operation was meant to remove special
populate-on-demand entries; if this removal fails, the internal
accounting becomes inconsistent and may eventually hit a BUG().
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.
An unprivileged guest can retain a writable mapping of freed memory.
Depending on how this page is used, it could result in either an
information leak, or full privilege escalation.
Alternatively, an unprivileged guest can cause Xen to hit a BUG(),
causing a clean crash - ie, host-wide denial-of-service (DoS).
All systems from Xen 3.4 are vulnerable.
Only x86 systems are vulnerable. ARM is not vulnerable.
x86 PV VMs cannot leverage the vulnerability.
Only systems with 2MiB or 1GiB HAP pages enabled are vulnerable.
The vulnerability is largely restricted to HVM guests which have been
constructed in Populate-on-Demand mode (i.e. with memory < maxmem):
x86 HVM domains without PoD (i.e. started with memory == maxmem, or
without mentioning "maxmem" in the guest config file) also cannot
leverage the vulnerability, in recent enough Xen versions:
4.8.x and later: all versions safe if PoD not configured
4.7.x: 4.7.1 and later safe if PoD not configured
4.6.x: 4.6.4 and later safe if PoD not configured
4.5.x: 4.5.4 and later safe if PoD not configured
4.4.x and earlier: all versions vulnerable even if PoD not configured
The commit required to prevent this vulnerability when PoD
not configured is 2a99aa99fc84a45f505f84802af56b006d14c52e
xen/physmap: Do not permit a guest to populate PoD pages for itself
and the corresponding backports.
Running only PV guests will avoid this issue.
Running HVM guests only in non-PoD mode (maxmem == memory) will also
avoid this issue. NOTE: In older releases of Xen, an HVM guest can
create PoD entries itself; so this mitigation will not be effective.
Specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will
also 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.)
This issue was discovered by George Dunlap of Citrix.
Applying the appropriate attached patch resolves this issue.
xsa247-4.9/*.patch Xen 4.9.x
xsa247-4.8/*.patch Xen 4.8.x
xsa247-4.7/*.patch Xen 4.7.x
xsa247-4.6/*.patch Xen 4.6.x
xsa247-4.5/*.patch Xen 4.5.x
$ sha256sum xsa247* xsa247*/*
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
administrators, with ONE exception:
Removing the ability to boot in populate-on-demand mode is NOT
permitted during the embargo on public cloud systems. This is because
doing so might alert attackers to the nature of the vulnerability.
Deployment of this mitigation is permitted only AFTER the embargo
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-announce mailing list
xsa247.meta (2K) Download Attachment
xsa247-4.5/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch (8K) Download Attachment
xsa247-4.5/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch (5K) Download Attachment
xsa247-4.6/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch (8K) Download Attachment
xsa247-4.6/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch (5K) Download Attachment
xsa247-4.7/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch (8K) Download Attachment
xsa247-4.7/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch (5K) Download Attachment
xsa247-4.8/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch (8K) Download Attachment
xsa247-4.8/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch (5K) Download Attachment
xsa247-4.9/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch (8K) Download Attachment
xsa247-4.9/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch (5K) Download Attachment
xsa247/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch (8K) Download Attachment
xsa247/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch (5K) Download Attachment
|Free forum by Nabble||Edit this page|