Mailing List Archive

Xen Security Advisory 389 v3 (CVE-2021-28705,CVE-2021-28709) - issues with partially successful P2M updates on x86
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Xen Security Advisory CVE-2021-28705,CVE-2021-28709 / XSA-389
version 3

issues with partially successful P2M updates on x86

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

Add CVE numbers to patches.

Public release.

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

x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode,
to provide a way for them to later easily have more memory assigned.

Guests are permitted to control certain P2M aspects of individual
pages via hypercalls. These hypercalls may act on ranges of pages
specified via page orders (resulting in a power-of-2 number of pages).
In some cases the hypervisor carries out the requests by splitting
them into smaller chunks. Error handling in certain PoD cases has
been insufficient in that in particular partial success of some
operations was not properly accounted for.

There are two code paths affected - page removal (CVE-2021-28705) and
insertion of new pages (CVE-2021-28709). (We provide one patch which
combines the fix to both issues.)

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 3.4 onwards are affected. Xen versions 3.3 and
older are believed to not be affected.

Only x86 HVM and PVH guests started in populate-on-demand mode are
believed to be able to leverage the vulnerability. Populate-on-demand
mode is activated when the guest's xl configuration file specifies a
"maxmem" value which is larger than the "memory" value.

MITIGATION
==========

Not starting x86 HVM or PVH guests in populate-on-demand mode is
believed to allow avoiding the vulnerability.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate 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.

xsa389.patch xen-unstable
xsa389-4.15.patch Xen 4.15.x
xsa389-4.14.patch Xen 4.14.x
xsa389-4.13.patch Xen 4.13.x
xsa389-4.12.patch Xen 4.12.x

$ sha256sum xsa389*
c00f5b07594a6459bdd6f7334acc373bc3b0c14a5b0e444ec624ac60f857fc6f xsa389.patch
bf0d66623c3239e334a17332035be5d7c7e33cfdd7f04f9b385f70ce8fa92752 xsa389-4.12.patch
2737affcf1e0fae5d412067ea8c7fe1cc91a28fa22f3f7e97a502cbd032582cc xsa389-4.13.patch
b243284679b32ab8c817a2e41562d8694d9781fa8096c268bb41b0cd91684baa xsa389-4.14.patch
0a213e141089fe7808eae067b3c43beed6c7d5887fa4c901e8f9352618788e5a xsa389-4.15.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.

HOWEVER, deployment of the 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/4UyVfoK9kFAmGc2jkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZkOAIAInsof4UP5VTDcLtiwCvGskCXZT0SwbJ5OKbmxG7
RmPJg+R5sy89aHyJ4BP4eRfgrfbG35qBSCB5zLHy2FR3oioRmDz3y4KAFP3hXJRc
B0hSNM9Al9nEfdt0YQeVxt297X0Ouz/bihLoHXKOTZ2AqKcafu9GRIdK0Kcj1v49
azcW1ndfAkIEYDGvtcdZDXYT3CyjLusQme3pweohZGwcQW6UYg7DhRKl0KPQZP/L
paQZd60walNWgDcV7qfMnWit2jYxF4AptLW8c+KFig7qorLE5z9Xj7AIJ6kGriry
fnwy/DE2xRr4IxWk/FsJgDxeAS6mv3KQ2Mpgx2bRAD0jB6I=
=3P7k
-----END PGP SIGNATURE-----