====================================================================

                             CERT-Renater

                 Note d'Information No. 2019/VULN409
_____________________________________________________________________

DATE                : 11/12/2019

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Xen.

=====================================================================
https://xenbits.xen.org/xsa/advisory-307.html
https://xenbits.xen.org/xsa/advisory-308.html
https://xenbits.xen.org/xsa/advisory-309.html
https://xenbits.xen.org/xsa/advisory-310.html
https://xenbits.xen.org/xsa/advisory-311.html
_____________________________________________________________________

    Xen Security Advisory CVE-2019-19581,CVE-2019-19582 / XSA-307
                              version 3

                        find_next_bit() issues

UPDATES IN VERSION 3
====================

Public release.

Updated metadata to add 4.13, update StableRef's

ISSUE DESCRIPTION
=================

In a number of places bitmaps are being used by the hypervisor to track
certain state.  Iteration over all bits involves functions which may
misbehave in certain corner cases:
- - On 32-bit Arm accesses to bitmaps with bit a count which is a multiple
  of 32, an out of bounds access may occur.  (CVE-2019-19581)
- - On x86 accesses to bitmaps with a compile time known size of 64 may
  incur undefined behavior, which may in particular result in infinite
  loops. (CVE-2019-19582)

IMPACT
======

A malicious guest may cause a hypervisor crash or hang, resulting in a
Denial of Service (DoS).

VULNERABLE SYSTEMS
==================

All versions of Xen are vulnerable.

32-bit Arm systems are vulnerable.

x86 systems with 64 or more nodes are vulnerable.  We are unaware of any
such systems that Xen would run on.

64-bit Arm systems as well as x86 systems with less than 64 nodes are
not vulnerable.

MITIGATION
==========

There is no known mitigation for 32-bit Arm systems.

For x86 systems the issue can be avoided by suppressing the use of NUMA
information provided by firmware, via the "numa=off" command line
option.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa307.patch           xen-unstable, Xen 4.13.x ... 4.8.x

$ sha256sum xsa307*
e589e96a0b3ec66f1d2d6393b82fab13ed18fd9fb112044a12263336b8499c68
xsa307.meta
7df052768cc05329bc44bf724897227885da8bb2cde9ff01d0ba2a34611bde97
xsa307.patch
$

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.

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
Team.

(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:
  http://www.xenproject.org/security-policy.html

_____________________________________________________________________


            Xen Security Advisory CVE-2019-19583 / XSA-308
                               version 3

     VMX: VMentry failure with debug exceptions and blocked states

UPDATES IN VERSION 3
====================

Public release.

Updated metadata to add 4.13, update StableRef's

ISSUE DESCRIPTION
=================

Please see XSA-260 for background on the MovSS shadow:
  http://xenbits.xen.org/xsa/advisory-260.html

Please see XSA-156 for background on the need for #DB interception:
  http://xenbits.xen.org/xsa/advisory-156.html

The VMX VMEntry checks does not like the exact combination of state
which occurs when #DB in intercepted, Single Stepping is active, and
blocked by STI/MovSS is active, despite this being a legitimate state to
be in.  The resulting VMEntry failure is fatal to the guest.

IMPACT
======

HVM/PVH guest userspace code may be able to crash the guest, resulting
in a guest Denial of Service.

VULNERABLE SYSTEMS
==================

All versions of Xen are affected.

Only systems supporting VMX hardware virtual extensions (Intel, Cyrix or
Zhaoxin CPUs) are affected. Arm and AMD systems are unaffected.

Only HVM/PVH guests are affected.  PV guests cannot leverage the
vulnerability.

MITIGATION
==========

Running only PV guests will avoid this vulnerability.

Running HVM guests on only AMD hardware will also avoid this
vulnerability.

CREDITS
=======

This issue was discovered by Håkon Alstadheim and diagnosed as a
security issue by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa308.patch           xen-unstable, Xen 4.13.x .. Xen 4.8.x

$ sha256sum xsa308*
4aa06d21478d9debb12388ff14d8abc31982e18895db40d0cec78fcc9fe68ef2
xsa308.meta
7e782b09b16f7534c8db52042f7bb3bd730d108571c8b10af184ae0b02fdae9d
xsa308.patch
$

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.

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
Team.
_____________________________________________________________________

            Xen Security Advisory CVE-2019-19578 / XSA-309
                               version 3

                Linear pagetable use / entry miscounts

UPDATES IN VERSION 3
====================

Public release.

Updated metadata to add 4.13, update StableRef's

ISSUE DESCRIPTION
=================

"Linear pagetables" is a technique which involves either pointing a
pagetable at itself, or to another pagetable of the same or higher
level.  Xen has limited support for linear pagetables: A page may
either point to itself, or point to another pagetable of the same
level (i.e., L2 to L2, L3 to L3, and so on).

XSA-240 introduced an additional restriction that limited the "depth"
of such chains by allowing pages to either *point to* other pages of
the same level, or *be pointed to* by other pages of the same level,
but not both.  To implement this, we keep track of the number of
outstanding times a page points to or is pointed to another page
table, to prevent both from happening at the same time.

Unfortunately, the original commit introducing this reset this count
when resuming validation of a partially-validated pagetable,
incorrectly dropping some "linear_pt_entry" counts.

If an attacker could engineer such a situation to occur, they might be
able to make loops or other arbitrary chains of linear pagetables, as
described in XSA-240.

IMPACT
======

A malicious or buggy PV guest may cause the hypervisor to crash,
resulting in Denial of Service (DoS) affecting the entire host.
Privilege escalation and information leaks cannot be excluded.

VULNERABLE SYSTEMS
==================

All versions of Xen are vulnerable.

Only x86 systems are affected.  Arm systems are not affected.

Only x86 PV guests can leverage the vulnerability.  x86 HVM and PVH
guests cannot leverage the vulnerability.

Only systems which have enabled linear pagetables are vulnerable.
Systems which have disabled linear pagetables, either by selecting
CONFIG_PV_LINEAR_PT=n when building the hypervisor, or adding
pv-linear-pt=false on the command-line, are not vulnerable.

MITIGATION
==========

If you don't have any guests which need linear pagetables, you can
disable the feature by adding pv-linear-pt=false to your Xen
command-line.  NetBSD is known to use linear pagetables; Linux and
MiniOS are known not to use linear pagetables.

CREDITS
=======

This issue was discovered by Manuel Bouyer and diagnosed as a security
issue by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa309.patch           xen-unstable, Xen 4.13 - Xen 4.8

$ sha256sum xsa309*
ddd00dfbc85bada4e4cee8a51b989e3138cc47c58992657054246bc95c8ae34d
xsa309.meta
0e4b75f4416624de698f3ed619c28418917ab0a5c9663c1641804e1d0a0dec1b
xsa309.patch
$

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.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Deployment of the `pv-linear-pt=false` 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 someone may notice the feature going away, and armed
with the knowledge of where the issue is, re-discover it.

Deployment of the mitigation is permitted only AFTER the embargo ends.
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(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:
  http://www.xenproject.org/security-policy.html

_____________________________________________________________________

            Xen Security Advisory CVE-2019-19580 / XSA-310
                               version 3

      Further issues with restartable PV type change operations

UPDATES IN VERSION 3
====================

Public release.

Updated metadata to add 4.13, update StableRef's

ISSUE DESCRIPTION
=================

XSA-299 addressed several critical issues in restartable PV type
change operations.  Despite extensive testing and auditing, some
corner cases were missed.

IMPACT
======

A malicious PV guest administrator may be able to escalate their
privilege to that of the host.

VULNERABLE SYSTEMS
==================

All security-supported versions of Xen are vulnerable.

Only x86 systems are affected.  Arm systems are not affected.

Only x86 PV guests can leverage the vulnerability.  x86 HVM and PVH
guests cannot leverage the vulnerability.

Note that these attacks require very precise timing, which may
be difficult to exploit in practice.

MITIGATION
==========

Running only HVM or PVH guests will avoid this vulnerability.

Running PV guests in "shim" mode will also avoid this vulnerability.

CREDITS
=======

This issue was discovered by Sarah Newman at prgmr.com.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa310/*.patch           xen-unstable, Xen 4.13 - 4.10
xsa310-4.9/*.patch       Xen 4.9 - 4.8

$ sha256sum xsa310* xsa310*/*
2208e40c71aa521ae487782bd751963ce696be451d10a179fcecdff7a0065369
xsa310.meta
8e75f0fb5fe890a661c8d46ec622131bc650f1a95b170b99569b50dd2224616c
xsa310-4.9/0001-x86-mm-Set-old_guest_table-when-destroying-vcpu-page.patch
3da404a0c088936ed92377ccef1fa6fdeb23900358ca9284e3488e8e1dcb5dd2
xsa310-4.9/0002-x86-mm-alloc-free_lN_table-Retain-partial_flags-on-E.patch
cd1a77c2f767474dcfbd1e6282ad3219ce2abcac2021b040120d40b52fc76bc8
xsa310-4.9/0003-x86-mm-relinquish_memory-Grab-an-extra-type-ref-when.patch
44c670a1b1b8164202766d52fb741e62c104118525eb7a3e56f4b232bcb8be3f
xsa310/0001-x86-mm-Set-old_guest_table-when-destroying-vcpu-page.patch
173dc0ffb4c572c8493bd9d5f3309b113e51888bdc9e462c78933f5c85f69b7a
xsa310/0002-x86-mm-alloc-free_lN_table-Retain-partial_flags-on-E.patch
1833fbfc2cdea9b37f161b09df947dffdd8db5e60a2f3512913de0e0c0d4b3ef
xsa310/0003-x86-mm-relinquish_memory-Grab-an-extra-type-ref-when.patch
$

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.

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
Team.


(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:
  http://www.xenproject.org/security-policy.html

_____________________________________________________________________

            Xen Security Advisory CVE-2019-19577 / XSA-311
                               version 4

         Bugs in dynamic height handling for AMD IOMMU pagetables

UPDATES IN VERSION 4
====================

Public release.

Re-base 4.12 patch onto latest stable tree commits.

Updated metadata to add 4.13, update StableRef's

ISSUE DESCRIPTION
=================

When running on AMD systems with an IOMMU, Xen attempted to
dynamically adapt the number of levels of pagetables (the pagetable
height) in the IOMMU according to the guest's address space size.  The
code to select and update the height had several bugs.

Notably, the update was done without taking a lock which is necessary
for safe operation.

IMPACT
======

A malicious guest administrator can cause Xen to access data
structures while they are being modified, causing Xen to crash.
Privilege escalation is thought to be very difficult but cannot be
ruled out.

Additionally, there is a potential memory leak of 4kb per guest boot,
under memory pressure.

VULNERABLE SYSTEMS
==================

Only Xen on AMD CPUs is vulnerable.  Xen running on Intel CPUs is not
vulnerable.  ARM systems are not vulnerable.

Only systems where guests are given direct access to physical devices
are vulnerable.  Systems which do not use PCI pass-through are not
vulnerable.

Only HVM guests can exploit the vulnerability.  PV and PVH guests
cannot.

All versions of Xen with IOMMU support are vulnerable.

MITIGATION
==========

In some configurations, use of passthrough can be replaced with a
higher-level protocol such as Xen PV block or network devices.
There is no other mitigation.

CREDITS
=======

This issue was discovered by Sander Eikelenboom, along with Andrew Cooper of
Citrix.

RESOLUTION
==========

Applying the appropriate (set of) attached patch(es) resolves this issue.

xsa311.patch           xen-unstable, Xen 4.13.x
xsa311-4.12.patch      Xen 4.12.x
xsa311-4.11.patch      Xen 4.11.x
xsa311-4.10-*.patch    Xen 4.10.x
xsa311-4.9-*.patch     Xen 4.9.x
xsa311-4.8-*.patch     Xen 4.8.x

$ sha256sum xsa311*
ea929752043b5d4659cb605314887441daa33ee6450e755d6f077e57fc7abf9e
xsa311.meta
732975f33b6d893b984540c4c748eb5cdf1cf81bd565e41b57795458cae3ccad
xsa311.patch
27e30da9360eec850f6e7d8f2ea465d2f00a5a5a45c43042e4c18786c6c9338f
xsa311-4.8-1.patch
6e2372eb18f3ca25093445a93bcdf674ed2d7d3012e8611911ea2b9ca8d58bd4
xsa311-4.8-2.patch
c73bee7aa8fac02d0982b4fb21de053918f80cc0158bd5bfca68e3dc994759be
xsa311-4.9-1.patch
e89f5c381bd6a8fa8c5f63a829b586fdbefefe311c0f1084d2baeea3e933da66
xsa311-4.9-2.patch
c73bee7aa8fac02d0982b4fb21de053918f80cc0158bd5bfca68e3dc994759be
xsa311-4.10-1.patch
189a51048ad88efd855e6e78a307fff68e0c139225ce528c253558d266fffe02
xsa311-4.10-2.patch
1aaf26d1c231c8b5dd00900c00c18bf884d23b9568c9746866d92f39daf1c02f
xsa311-4.11.patch
5f43fa4628f6d1a8f6f903e662226a09524b8c354e06e1a6039837db656c0218
xsa311-4.12.patch
$

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.

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
Team.


(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:
  http://www.xenproject.org/security-policy.html

=========================================================
+ CERT-RENATER        | tel : 01-53-94-20-44            +
+ 23/25 Rue Daviel    | fax : 01-53-94-20-41            +
+ 75013 Paris         | email:cert@support.renater.fr   +
=========================================================