Information

Files

Advisory

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

            Xen Security Advisory CVE-2021-28699 / XSA-382
                               version 2

         inadequate grant-v2 status frames array bounds check

UPDATES IN VERSION 2
====================

Public release.

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

The v2 grant table interface separates grant attributes from grant
status.  That is, when operating in this mode, a guest has two tables.
As a result, guests also need to be able to retrieve the addresses that
the new status tracking table can be accessed through.

For 32-bit guests on x86, translation of requests has to occur because
the interface structure layouts commonly differ between 32- and 64-bit.

The translation of the request to obtain the frame numbers of the
grant status table involves translating the resulting array of frame
numbers.  Since the space used to carry out the translation is limited,
the translation layer tells the core function the capacity of the array
within translation space.  Unfortunately the core function then only
enforces array bounds to be below 8 times the specified value, and would
write past the available space if enough frame numbers needed storing.

IMPACT
======

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.  Privilege escalation
and information leaks cannot be ruled out.

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

All Xen versions from 4.10 onwards are affected.  Xen versions 4.9 and
older are not affected.

Only 32-bit x86 guests permitted to use grant table version 2 interfaces
can leverage this vulnerability.  64-bit x86 guests cannot leverage this
vulnerability, but note that HVM and PVH guests are free to alter their
bitness as they see fit.  On Arm, grant table v2 use is explicitly
unsupported.

Only guests permitted to have 8177 or more grant table frames can
leverage this vulnerability.

MITIGATION
==========

The problem can be avoided by not increasing too much the number of
grants Xen would allow guests to establish.  The limit is controlled by
the "gnttab_max_frames" Xen command line option and the
"max_grant_frames" xl domain configuration setting.

- From Xen 4.14 onwards it is also possible to alter the system wide upper
bound of the number of grants Xen would allow guests to establish by
writing to the /params/gnttab_max_frames hypervisor file system node.
Note however that changing the value this way will only affect guests
yet to be created on the respective host.

Suppressing use of grant table v2 interfaces for 32-bit x86 guests will
also avoid this vulnerability.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

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.

xsa382.patch           xen-unstable - Xen 4.11.x

$ sha256sum xsa382*
1254d62c8ec2c6b45c117d1483af9a71f5de0e4142c9451dd5a75ee334219542  xsa382.meta
9e500ba2bfe36bebf27262afcb9be7b02f950aed4a7b6c1738606d5ed538c2b8  xsa382.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or grant-frames-limiting mitigation
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, care has to be taken to avoid restricting guests too much, as
them suddenly being unable to establish grants they used to be able to
establish may lead to re-discovery of the issue.

AND: Deployment of the grant table v2 disabling mitigation described
above is NOT permitted during the embargo on public-facing systems with
untrusted guest users and administrators.  This is because such a
configuration change is recognizable by the affected guests.

AND: 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/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZwnkIALnDReUPP6qoQzBWHf9s93UPwM6YVdHl/ao1Nh9l
IyMGtTKjJjtYR9at0tIJDmVecFZzsBtLhQlKWe5DvNP84ZQ99EGDjzsqYKGdJMZK
QIfyUz74UKN5PwEzxeT2C3Q9tOIq2NA41Vax19MjAXSbvAi3jp/0CSj7i6h+bK5f
WoBX9Av8Ie2ykF3Fe5i7yNl9gMpCyqEl3dijWwjezLIxlxzdBrjbKni+yBvmLBS9
XdS++bu9LwAbQXeDc5oB0b6mvy+7oHzEJfvCH+tA6o6V6bls94sF8owi5H52rn1n
23HzFQwbwqX9wmW5OKSS/NBzI9vJwzRCyOEVQw+eaZQGiHw=
=kWGv
-----END PGP SIGNATURE-----