Xen Security Advisory 207 - memory leak when destroying guest without PT devices

Xen Security Advisory 207 - memory leak when destroying guest without PT devices

[Xen.org security team]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                    Xen Security Advisory XSA-207
                              version 2

         memory leak when destroying guest without PT devices

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

Public release.

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

Certain internal state is set up, during domain construction, in
preparation for possible pass-through device assignment.  On ARM and
AMD V-i hardware this setup includes memory allocation.  On guest
teardown, cleanup was erroneously only performed when the guest
actually had a pass-through device assigned.

IMPACT
======

A malicious guest may, by frequently rebooting over extended periods
of time, run the system out of memory, resulting in a Denial of
Service (DoS).

The leak is no more than 4kbytes per guest boot.

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

Xen versions 3.3 and later are affected.

ARM systems, and x86 AMD systems, are affected.  Intel systems, and
systems without IOMMU/SMMU hardware, are unaffected.

All guest kinds can exploit this vulnerability.

MITIGATION
==========

Limiting the frequency with which a guest is able to reboot, will
limit the memory leak.

Rebooting each host (after migrating its guests) periodically will
reclaim the leaked space.

CREDITS
=======

This issue was discovered by Oleksandr Tyshchenko of EPAM Systems.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa207.patch           xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x
xsa207-4.4.patch       Xen 4.4.x

$ sha256sum xsa207*
e9bcf807b3785ac4d78b621fba4a9395cd713d6e57cdaa66559bccf95ded1cd9  xsa207.patch
5f391cc621d619ee33c90398bda24588ebf8320750db4545677bb5222150ae6d  xsa207-4.4.patch
$

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

Deployment of the patches described above is permitted during the
embargo, as is the mitigation of migrating a VM which has no devices
assigned from IOMMU-capable hardware to IOMMU-incapable hardware, even
on public-facing systems with untrusted guest users and administrators.

HOWEVER, moving a VM from AMD to Intel hardware, in response to this
vulnerability, is *not* permitted.  This is because such a change is
visible to guests, and would not normally be expected.

Furthermore: 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-----
Version: GnuPG v1

iQEcBAEBAgAGBQJYpEP+AAoJEIP+FMlX6CvZPrMIAL7ULaO/oOicZzGHzMO0f1r6
MZDBPeLAg5EQ3oGl1oZenlEEQgSflzj2YHdwjdps2kZpJBaRJjNPmqOC3ZxetlyF
+cEJWpw6u0IDRzukEWkQlFGQS68ShLjRcKWDi5+ftjo4rFh34uybrgRv7/nKtiuG
ZLX7dqKZuqYBSYvSXjA8UejB//psGOu4jqNh15t0bxtQqc5BlgdJebOkKlgrxL2M
BqI/kiZoRuKkDVBu2786oo3w8BCjyBktDR0B9dzRY6MEdTXqb+mE8IO7G492KQTk
/ZW9rKeijauKLNgsSkZlqtA0TPTp7tujh9XxE/JfB8UcYFez86NWoBBY4g+Q3SQ=
=kwFG
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa207.patch --]
[-- Type: application/octet-stream, Size: 1026 bytes --]

From: Oleksandr Tyshchenko <olekstysh@gmail.com>
Subject: IOMMU: always call teardown callback

There is a possible scenario when (d)->need_iommu remains unset
during guest domain execution. For example, when no devices
were assigned to it. Taking into account that teardown callback
is not called when (d)->need_iommu is unset we might have unreleased
resourses after destroying domain.

So, always call teardown callback to roll back actions
that were performed in init callback.

This is XSA-207.

Signed-off-by: Oleksandr Tyshchenko <olekstysh@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Julien Grall <julien.grall@arm.com>

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -244,8 +244,7 @@ void iommu_domain_destroy(struct domain
     if ( !iommu_enabled || !dom_iommu(d)->platform_ops )
         return;
 
-    if ( need_iommu(d) )
-        iommu_teardown(d);
+    iommu_teardown(d);
 
     arch_iommu_domain_destroy(d);
 }

[-- Attachment #3: xsa207-4.4.patch --]
[-- Type: application/octet-stream, Size: 1052 bytes --]

From: Oleksandr Tyshchenko <olekstysh@gmail.com>
Subject: IOMMU: always call teardown callback

There is a possible scenario when (d)->need_iommu remains unset
during guest domain execution. For example, when no devices
were assigned to it. Taking into account that teardown callback
is not called when (d)->need_iommu is unset we might have unreleased
resourses after destroying domain.

So, always call teardown callback to roll back actions
that were performed in init callback.

This is XSA-207.

Signed-off-by: Oleksandr Tyshchenko <olekstysh@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Julien Grall <julien.grall@arm.com>

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -418,8 +418,7 @@ void iommu_domain_destroy(struct domain
     if ( !iommu_enabled || !hd->platform_ops )
         return;
 
-    if ( need_iommu(d) )
-        iommu_teardown(d);
+    iommu_teardown(d);
 
     list_for_each_safe ( ioport_list, tmp, &hd->g2m_ioport_list )
     {

[-- Attachment #4: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel