Xen Security Advisory 340 v3 (CVE-2020-25603) - Missing memory barriers when accessing/allocating an event channel

Xen Security Advisory 340 v3 (CVE-2020-25603) - Missing memory barriers when accessing/allocating an event channel

[Xen.org security team]

[-- Attachment #1: Type: text/plain, Size: 3613 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2020-25603 / XSA-340
                               version 3

  Missing memory barriers when accessing/allocating an event channel

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

Public release.

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

Event channels control structures can be accessed lockless as long as the port
is considered to be valid. Such sequence is missing appropriate memory barrier
(e.g smp_*mb()) to prevent both the compiler and CPU to re-order access.

IMPACT
======

A malicious guest may be able to cause a hypervisor crash resulting in a
Denial of Service (DoS). Information leak and privilege escalation cannot be
excluded.

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

Systems running all versions of Xen are affected.  Whether a system is
vulnerable will depend on the CPU and compiler used to build Xen.

For all the systems, the presence and the scope of the vulnerability
depends on the precise re-ordering performed by the compiler used to
build Xen.

We have not been able to survey compilers; consequently we cannot say
which compiler(s) might produce vulnerable code (with which code generation
options).  GCC documentation clearly suggests that re-ordering is possible.

Arm systems will also be vulnerable if the CPU is able to re-order memory
access.  Please consult your CPU vendor.

x86 systems are only vulnerable if a compiler performs re-ordering.

MITIGATION
==========

There is no known mitigation.

CREDITS
=======

This issue was discovered by Julien Grall of Amazon.

RESOLUTION
==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa340.patch           Xen 4.10 - xen-unstable

$ sha256sum xsa340*
72b75011b99e914ddb479082f88329063dcd1f55cc931059d950ecda276ee944  xsa340.meta
2bb088fcc1f8f79bf5ddb7b4e101cb1db76a343d2fb1cdafb7cd54612e4009da  xsa340.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
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZaBsH/RbQVpTAfl0zd7RyKXO34WZnWsYfwC+l8erEtf51
rmETfcqQP5rjNZZKEIDWcoYbJQU1DdC5tfVarUEYbGzCxPyBXlckcNKWmIVpkWnC
i+/XBALNjErN3AoJJOc8Tb3nfOZJlRrh3PXaqFo+xOqBn2vijgQJCXlpr1yRLDov
CatUy5DWmzVWVgByrkHs9Y+hsK7hb+DzxFvNiZUE7kv8a+R3F3smNgXDe/N7AasL
ZCJNVpfJGjqpk+EnffaTti9gd2aPxxzzmsWAoiW0C/6s/eJckhj/LxF7ZG5WbuVT
inhxm6zkQwBwvSTM7GLZpOuPXPegI8/RX+fO6lqsD0bcuQo=
=J1Xd
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa340.meta --]
[-- Type: application/octet-stream, Size: 2163 bytes --]

{
  "XSA": 340,
  "SupportedVersions": [
    "master",
    "4.14",
    "4.13",
    "4.12",
    "4.11",
    "4.10"
  ],
  "Trees": [
    "xen"
  ],
  "Recipes": {
    "4.10": {
      "Recipes": {
        "xen": {
          "StableRef": "93be943e7d759015bd5db41a48f6dce58e580d5a",
          "Prereqs": [
            336,
            337,
            338,
            339
          ],
          "Patches": [
            "xsa340.patch"
          ]
        }
      }
    },
    "4.11": {
      "Recipes": {
        "xen": {
          "StableRef": "ddaaccbbab6b19bf21ed2c097f3055a3c2544c8d",
          "Prereqs": [
            333,
            336,
            337,
            338,
            339
          ],
          "Patches": [
            "xsa340.patch"
          ]
        }
      }
    },
    "4.12": {
      "Recipes": {
        "xen": {
          "StableRef": "1336ca17742471fc4a59879ae2f637a59530a933",
          "Prereqs": [
            333,
            334,
            336,
            337,
            338,
            339
          ],
          "Patches": [
            "xsa340.patch"
          ]
        }
      }
    },
    "4.13": {
      "Recipes": {
        "xen": {
          "StableRef": "9b367b2b0b714f3ffb69ed6be0a118e8d3eac07f",
          "Prereqs": [
            333,
            334,
            336,
            337,
            338,
            339
          ],
          "Patches": [
            "xsa340.patch"
          ]
        }
      }
    },
    "4.14": {
      "Recipes": {
        "xen": {
          "StableRef": "c3a0fc22af90ef28e68b116c6a49d9cec57f71cf",
          "Prereqs": [
            333,
            334,
            336,
            337,
            338,
            339
          ],
          "Patches": [
            "xsa340.patch"
          ]
        }
      }
    },
    "master": {
      "Recipes": {
        "xen": {
          "StableRef": "b11910082d90bb1597f6679524eb726a33306672",
          "Prereqs": [
            333,
            334,
            336,
            337,
            338,
            339
          ],
          "Patches": [
            "xsa340.patch"
          ]
        }
      }
    }
  }
}

[-- Attachment #3: xsa340.patch --]
[-- Type: application/octet-stream, Size: 2403 bytes --]

From: Julien Grall <jgrall@amazon.com>
Subject: xen/evtchn: Add missing barriers when accessing/allocating an event channel

While the allocation of a bucket is always performed with the per-domain
lock, the bucket may be accessed without the lock taken (for instance, see
evtchn_send()).

Instead such sites relies on port_is_valid() to return a non-zero value
when the port has a struct evtchn associated to it. The function will
mostly check whether the port is less than d->valid_evtchns as all the
buckets/event channels should be allocated up to that point.

Unfortunately a compiler is free to re-order the assignment in
evtchn_allocate_port() so it would be possible to have d->valid_evtchns
updated before the new bucket has finish to allocate.

Additionally on Arm, even if this was compiled "correctly", the
processor can still re-order the memory access.

Add a write memory barrier in the allocation side and a read memory
barrier when the port is valid to prevent any re-ordering issue.

This is XSA-340.

Reported-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -178,6 +178,13 @@ int evtchn_allocate_port(struct domain *
             return -ENOMEM;
         bucket_from_port(d, port) = chn;

+        /*
+         * d->valid_evtchns is used to check whether the bucket can be
+         * accessed without the per-domain lock. Therefore,
+         * d->valid_evtchns should be seen *after* the new bucket has
+         * been setup.
+         */
+        smp_wmb();
         write_atomic(&d->valid_evtchns, d->valid_evtchns + EVTCHNS_PER_BUCKET);
     }

--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -107,7 +107,17 @@ void notify_via_xen_event_channel(struct

 static inline bool_t port_is_valid(struct domain *d, unsigned int p)
 {
-    return p < read_atomic(&d->valid_evtchns);
+    if ( p >= read_atomic(&d->valid_evtchns) )
+        return false;
+
+    /*
+     * The caller will usually access the event channel afterwards and
+     * may be done without taking the per-domain lock. The barrier is
+     * going in pair the smp_wmb() barrier in evtchn_allocate_port().
+     */
+    smp_rmb();
+
+    return true;
 }

 static inline struct evtchn *evtchn_from_port(struct domain *d, unsigned int p)