Xen Security Advisory 316 v3 (CVE-2020-11743) - Bad error path in GNTTABOP_map_grant

Xen Security Advisory 316 v3 (CVE-2020-11743) - Bad error path in GNTTABOP_map_grant

[Xen.org security team]

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

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

            Xen Security Advisory CVE-2020-11743 / XSA-316
                               version 3

                 Bad error path in GNTTABOP_map_grant

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

Public release.

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

Grant table operations are expected to return 0 for success, and a
negative number for errors.  Some misplaced brackets cause one error
path to return 1 instead of a negative value.

The grant table code in Linux treats this condition as success, and
proceeds with incorrectly initialised state.

IMPACT
======

A buggy or malicious guest can construct its grant table in such a way
that, when a backend domain tries to map a grant, it hits the incorrect
error path.

This will crash a Linux based dom0 or backend domain.

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

Systems running any version of Xen with the XSA-295 fixes are
vulnerable.  Systems which have not yet taken the XSA-295 fixes are not
vulnerable.

Systems running a Linux based dom0 or driver domain are vulnerable.

Systems running a FreeBSD or NetBSD based dom0 or driver domain are not
impacted, as they both treat any nonzero value as a failure.

The vulnerability of other systems will depend on how they behave when
getting an unexpected positive number from the GNTTABOP_map_grant
hypercall.

MITIGATION
==========

Applying the Linux patches alone is sufficient to mitigate the issue.
This might be a preferred route for downstreams who support livepatching
Linux but not Xen.

CREDITS
=======

This issue was discovered by Ross Lagerwall of Citrix.

RESOLUTION
==========

Applying the appropriate Xen patch will resolve this issue.

Additionally, a Linux patch is provided to make Linux's behaviour more
robust to unexpected values.

We recommend taking both patches if at all possible.

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.

xsa316/xsa316-xen.patch       Xen 4.9 - xen-unstable
xsa316/xsa316-linux.patch     Linux

$ sha256sum xsa316*/*
7dcd02e8cc0434046747d572bc6c77cd3a2e4041eefd2fa703f4130e998b58dd  xsa316/xsa316-linux.patch
4007578e30730861750d8808c0b63f2e03bbb05df909d71de19201084816a8b9  xsa316/xsa316-xen.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/4UyVfoK9kFAl6Vpd0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZjOgH/1xKsvqDnR04knl9OWvgL690gqxZpwliRRDwwkWh
1kOHJq2jsvm5bq38fYY9WpvmtvHW/RoM53Kacyz1Rl0y9VvK6hDU7P5np4WkMueX
iEJOcIbQau1Pg8/zD8hYkqNNGTCjb79ZhggTih1HxpeZJTa7TJv9bNsZpCQkw+P/
EBXpfsqoPqAMN1qt5PclCT5zlasyBUVjW6+lF3tF6q77knQoWNpKbIOSqL2/V2/p
vUMP/qyUikWW8JLH8N48jpRmFzjxwoDI4/3E1sbSv2VxlX1FksbZxan1cwcjoSG6
004GYSxqOjP4oPEAOrC6sXxc6DKoLLa8SVzYNhkg3XoScY0=
=qCJA
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa316/xsa316-linux.patch --]
[-- Type: application/octet-stream, Size: 1455 bytes --]

From: Juergen Gross <jgross@suse.com>
Subject: xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index e17ca8156171..a38292ef79f6 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -448,7 +448,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
 			   unsigned int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	int err;
+
+	err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+	/* Some hypervisors are buggy and can return 1. */
+	if (err > 0)
+		err = GNTST_general_error;
+
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 

[-- Attachment #3: xsa316/xsa316-xen.patch --]
[-- Type: application/octet-stream, Size: 1168 bytes --]

From: Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: xen/gnttab: Fix error path in map_grant_ref()

Part of XSA-295 (c/s 863e74eb2cffb) inadvertently re-positioned the brackets,
changing the logic.  If the _set_status() call fails, the grant_map hypercall
would fail with a status of 1 (rc != GNTST_okay) instead of the expected
negative GNTST_* error.

This error path can be taken due to bad guest state, and causes net/blk-back
in Linux to crash.

This is XSA-316.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 9fd6e60416..4b5344dc21 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1031,7 +1031,7 @@ map_grant_ref(
     {
         if ( (rc = _set_status(shah, status, rd, rgt->gt_version, act,
                                op->flags & GNTMAP_readonly, 1,
-                               ld->domain_id) != GNTST_okay) )
+                               ld->domain_id)) != GNTST_okay )
             goto act_release_out;
 
         if ( !act->pin )