xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Xen Security Advisory 22 (CVE-2012-4537) - Memory mapping failure DoS vulnerability
@ 2012-11-13 12:56 Xen.org security team
  0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2012-11-13 12:56 UTC (permalink / raw)
  To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team

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

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

                 Xen Security Advisory CVE-2012-4537 / XSA-22
			      version 4

                  Memory mapping failure DoS vulnerability

UPDATES IN VERSION 4
====================

Public release.

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

When set_p2m_entry fails, Xen's internal data structures (the p2m and
m2p tables) can get out of sync.  This failure can be triggered by
unusual guest behaviour exhausting the memory reserved for the p2m
table.  If it happens, subsequent guest-invoked memory operations can
cause Xen to fail an assertion and crash.

IMPACT
======

A malicious guest administrator might be able to cause Xen to crash.

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

All versions of Xen since at least 3.4 are vulnerable.

The vulnerability is only exposed to HVM guests.

MITIGATION
==========

There is no mitigation available other than to use a trusted guest
kernel.

RESOLUTION
==========

The attached patch resolves this issue.

Applying the appropriate attached patch resolves this issue.

xsa22-4.2-unstable.patch    Xen 4.2.x, xen-unstable
xsa22-4.1.patch             Xen 4.1.x
xsa22-4.0.patch             Xen 4.0.x
xsa22-3.4.patch             Xen 3.4.x

$ sha256sum xsa22*.patch
fe21558f098340451a275c468a7b2209915676f4f41ec394970c6aa0df3d93d3  xsa22-3.4.patch
b7e635ae07f31ac8ecb8732152ba66897ea6d0f5e30468e35d7c37379c7369bb  xsa22-4.0.patch
e699e7af6b90e60531d98f04197141c4caf5eb4cdb312a43e736830eb17d32e1  xsa22-4.1.patch
8dbf850b903179807257febe12a15cb131968e65d2e90dbd3a5f72b83d2f931a  xsa22-4.2-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQokGpAAoJEIP+FMlX6CvZUsEIAIL7FtUpAgYTG73BXIpIoJ1h
L85yaAhizzuwWAHMwLBD/oMs+OPzIXsCp4rBHI8XPQ0rf3YeHSj8uI+ta17Th1Gb
KuFFlDPujh5EiE0yel8u21hgsJ7rUpA04jPeYDbVbHPVC6bywf7pkChCEPos/Ze9
gAlRVptdBXH2nGmSyMFDfoby60lDXa7ZP0KoJUyuUG69zDMzlANLiEvk/+mN4YKB
W4uiaYlCeDfrCn4T8Pk9rTMdDWmCsbQpZQRqwwNXdUa/EX0Ccv/QdcppPHoylYeK
DQ9GPZOtDsm4s1M/J1oPVXZI7X/vLuBwje4/hhisFFiO4kLffcKCSopSizgLlO0=
=82B5
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa22-3.4.patch --]
[-- Type: application/octet-stream, Size: 2044 bytes --]

x86/physmap: Prevent incorrect updates of m2p mappings

In certain conditions, such as low memory, set_p2m_entry() can fail.
Currently, the p2m and m2p tables will get out of sync because we still
update the m2p table after the p2m update has failed.

If that happens, subsequent guest-invoked memory operations can cause
BUG()s and ASSERT()s to kill Xen.

This is fixed by only updating the m2p table iff the p2m was
successfully updated.

This is a security problem, XSA-22 / CVE-2012-4537.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ Add backport of 20516:c4e620a2e65c to correct error return from set_p2m_entry ]

diff -r 14709d196e43 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Wed Jun 30 18:26:13 2010 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Oct 26 11:27:44 2012 +0100
@@ -1500,14 +1500,15 @@ int set_p2m_entry(struct domain *d, unsi
 {
     unsigned long todo = 1ul << page_order;
     unsigned int order;
-    int rc = 0;
+    int rc = 1;
 
     while ( todo )
     {
         order = ((((gfn | mfn_x(mfn) | todo) & (SUPERPAGE_PAGES - 1)) == 0) &&
                  hvm_hap_has_2mb(d)) ? 9 : 0;
 
-        rc = d->arch.p2m->set_entry(d, gfn, mfn, order, p2mt);
+        if ( !d->arch.p2m->set_entry(d, gfn, mfn, order, p2mt) )
+            rc = 0;
         gfn += 1ul << order;
         if ( mfn_x(mfn) != INVALID_MFN )
             mfn = _mfn(mfn_x(mfn) + (1ul << order));
@@ -2054,7 +2055,10 @@ guest_physmap_add_entry(struct domain *d
     if ( mfn_valid(_mfn(mfn)) ) 
     {
         if ( !set_p2m_entry(d, gfn, _mfn(mfn), page_order, t) )
+        {
             rc = -EINVAL;
+            goto out; /* Failed to update p2m, bail without updating m2p. */
+        }
         for ( i = 0; i < (1UL << page_order); i++ )
             set_gpfn_from_mfn(mfn+i, gfn+i);
     }
@@ -2072,6 +2076,7 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
+out:
     audit_p2m(d);
     p2m_unlock(d->arch.p2m);
 

[-- Attachment #3: xsa22-4.0.patch --]
[-- Type: application/octet-stream, Size: 1288 bytes --]

x86/physmap: Prevent incorrect updates of m2p mappings

In certain conditions, such as low memory, set_p2m_entry() can fail.
Currently, the p2m and m2p tables will get out of sync because we still
update the m2p table after the p2m update has failed.

If that happens, subsequent guest-invoked memory operations can cause
BUG()s and ASSERT()s to kill Xen.

This is fixed by only updating the m2p table iff the p2m was
successfully updated.

This is a security problem, XSA-22 / CVE-2012-4537.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b44c72f18f9f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2207,7 +2207,10 @@ guest_physmap_add_entry(struct domain *d
     if ( mfn_valid(_mfn(mfn)) ) 
     {
         if ( !set_p2m_entry(d, gfn, _mfn(mfn), page_order, t) )
+        {
             rc = -EINVAL;
+            goto out; /* Failed to update p2m, bail without updating m2p. */
+        }
         if ( !p2m_is_grant(t) )
         {
             for ( i = 0; i < (1UL << page_order); i++ )
@@ -2228,6 +2231,7 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
+out:
     audit_p2m(d);
     p2m_unlock(d->arch.p2m);
 

[-- Attachment #4: xsa22-4.1.patch --]
[-- Type: application/octet-stream, Size: 1308 bytes --]

x86/physmap: Prevent incorrect updates of m2p mappings

In certain conditions, such as low memory, set_p2m_entry() can fail.
Currently, the p2m and m2p tables will get out of sync because we still
update the m2p table after the p2m update has failed.

If that happens, subsequent guest-invoked memory operations can cause
BUG()s and ASSERT()s to kill Xen.

This is fixed by only updating the m2p table iff the p2m was
successfully updated.

This is a security problem, XSA-22 / CVE-2012-4537.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3a27f4e44b6a xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2558,7 +2558,10 @@ guest_physmap_add_entry(struct p2m_domai
     if ( mfn_valid(_mfn(mfn)) ) 
     {
         if ( !set_p2m_entry(p2m, gfn, _mfn(mfn), page_order, t, p2m->default_access) )
+        {
             rc = -EINVAL;
+            goto out; /* Failed to update p2m, bail without updating m2p. */
+        }
         if ( !p2m_is_grant(t) )
         {
             for ( i = 0; i < (1UL << page_order); i++ )
@@ -2579,6 +2582,7 @@ guest_physmap_add_entry(struct p2m_domai
         }
     }
 
+out:
     audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 

[-- Attachment #5: xsa22-4.2-unstable.patch --]
[-- Type: application/octet-stream, Size: 1296 bytes --]

x86/physmap: Prevent incorrect updates of m2p mappings

In certain conditions, such as low memory, set_p2m_entry() can fail.
Currently, the p2m and m2p tables will get out of sync because we still
update the m2p table after the p2m update has failed.

If that happens, subsequent guest-invoked memory operations can cause
BUG()s and ASSERT()s to kill Xen.

This is fixed by only updating the m2p table iff the p2m was
successfully updated.

This is a security problem, XSA-22 / CVE-2012-4537.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r f53b9f915c3d xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -633,7 +633,10 @@ guest_physmap_add_entry(struct domain *d
     if ( mfn_valid(_mfn(mfn)) ) 
     {
         if ( !set_p2m_entry(p2m, gfn, _mfn(mfn), page_order, t, p2m->default_access) )
+        {
             rc = -EINVAL;
+            goto out; /* Failed to update p2m, bail without updating m2p. */
+        }
         if ( !p2m_is_grant(t) )
         {
             for ( i = 0; i < (1UL << page_order); i++ )
@@ -656,6 +659,7 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
+out:
     p2m_unlock(p2m);
 
     return rc;

[-- Attachment #6: Type: text/plain, Size: 126 bytes --]

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-11-13 12:56 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-13 12:56 Xen Security Advisory 22 (CVE-2012-4537) - Memory mapping failure DoS vulnerability Xen.org security team

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).