From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
xen-users@lists.xen.org, oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Subject: Xen Security Advisory 242 (CVE-2017-15593) - page type reference leak on x86
Date: Wed, 18 Oct 2017 12:08:35 +0000 [thread overview]
Message-ID: <E1e4n9I-0001M6-06@xenbits.xenproject.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2017-15593 / XSA-242
version 3
page type reference leak on x86
UPDATES IN VERSION 3
====================
CVE assigned.
ISSUE DESCRIPTION
=================
The page type system of Xen requires cleanup when the last reference
for a given page is being dropped. In order to exclude simultaneous
updates to a given page by multiple parties, pages which are updated
are locked beforehand. This locking includes temporarily increasing
the type reference count by one. When the page is later unlocked, the
context precludes cleanup, so the reference that is then dropped must
not be the last one. This was not properly enforced.
IMPACT
======
A malicious or buggy PV guest may cause a memory leak upon shutdown
of the guest, ultimately perhaps resulting in Denial of Service (DoS)
affecting the entire host.
VULNERABLE SYSTEMS
==================
All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and
earlier are not vulnerable.
Only x86 systems are affected. ARM systems are not affected.
Only x86 PV guests can leverage the vulnerability. x86 HVM guests
cannot leverage the vulnerability.
MITIGATION
==========
Running only HVM guests will avoid this vulnerability.
For PV guests, the vulnerability can be avoided if the guest kernel is
controlled by the host rather than guest administrator, provided that
further steps are taken to prevent the guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.
CREDITS
=======
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa242.patch xen-unstable
xsa242-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x
$ sha256sum xsa242*
168db3aef00806025afa255dee35cd0c042706a27a0256744e4d63f3ee86a2e8 xsa242.meta
16848f71311c2fd6a38afd7602e59211c89a3daf29b874097dba0b1e31ba6eec xsa242.patch
5e66b6b1d1cd400905d3abd3478144539c3afa24f5a744a11809d9c5eb517b98 xsa242-4.9.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-----
Version: GnuPG v1
iQEcBAEBCAAGBQJZ50QmAAoJEIP+FMlX6CvZ8KMIALNhUmBoSrrx6V16Z8rPKRTs
uBJ9b5KcUs6aiOvTD8HnGpukF5g4W+O4MzGY0WkIGjUIXgYYj4Fjnib+40x99Bp0
W6m7EMfkU3N9hg4BPAy33MHEwK/kC9TNxro3IxYXCzSZzZn6FG64x2j1gULZvz66
+mAIaiSF0cvrn/uB1aBoAW6z+kCtqq7+XzzeC61hHmEYseYa+5JY20xB0zJ9hQe2
KER5QTzySFsbLv/3uQ2KamQK318YBzVuFry04/ZFOXJFlz9UdP74xcRyCXuaWQCV
EGehp54ri3qqPv5Cc2tAKATbllIrHWizhF9dtM5vnXkvFKjh3jq8cszmuRga9zI=
=Y0V/
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa242.meta --]
[-- Type: application/octet-stream, Size: 2287 bytes --]
{
"XSA": 242,
"SupportedVersions": [
"master",
"4.9",
"4.8",
"4.7",
"4.6",
"4.5"
],
"Trees": [
"xen"
],
"Recipes": {
"4.5": {
"XenVersion": "4.5",
"Recipes": {
"xen": {
"StableRef": "83724d9f3ae21a3b96362742e2f052b19d9f559a",
"Prereqs": [
237,
238,
239,
240,
241
],
"Patches": [
"xsa242-4.9.patch"
]
}
}
},
"4.6": {
"XenVersion": "4.6",
"Recipes": {
"xen": {
"StableRef": "1658a87690ac839e85db12bbf409be62bb938640",
"Prereqs": [
237,
238,
239,
240,
241
],
"Patches": [
"xsa242-4.9.patch"
]
}
}
},
"4.7": {
"XenVersion": "4.7",
"Recipes": {
"xen": {
"StableRef": "c7783d9c26fc191862d9883da22387340b1fab18",
"Prereqs": [
237,
238,
239,
240,
241
],
"Patches": [
"xsa242-4.9.patch"
]
}
}
},
"4.8": {
"XenVersion": "4.8",
"Recipes": {
"xen": {
"StableRef": "36898eb12572f0a1f85cb54d4a9e90afcb6f7045",
"Prereqs": [
237,
238,
239,
240,
241
],
"Patches": [
"xsa242-4.9.patch"
]
}
}
},
"4.9": {
"XenVersion": "4.9",
"Recipes": {
"xen": {
"StableRef": "2cc3d32f40c71cb242477a3f8938074d4fc36829",
"Prereqs": [
237,
238,
239,
240,
241
],
"Patches": [
"xsa242-4.9.patch"
]
}
}
},
"master": {
"XenVersion": "master",
"Recipes": {
"xen": {
"StableRef": "a8ea6e2688118a3e19e29b39e316faa5f96ab9d1",
"Prereqs": [
237,
238,
239,
240,
241
],
"Patches": [
"xsa242.patch"
]
}
}
}
}
}
[-- Attachment #3: xsa242.patch --]
[-- Type: application/octet-stream, Size: 1715 bytes --]
From b2d245c0e7290614798969411614c1902300aafb Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich@suse.com>
Date: Wed, 27 Sep 2017 11:00:56 +0100
Subject: [PATCH] x86: don't allow page_unlock() to drop the last type
reference
Only _put_page_type() does the necessary cleanup, and hence not all
domain pages can be released during guest cleanup (leaving around
zombie domains) if we get this wrong.
This is XSA-242.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/mm.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index ab8f93935c..d883f1d648 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1705,7 +1705,11 @@ void page_unlock(struct page_info *page)
do {
x = y;
+ ASSERT((x & PGT_count_mask) && (x & PGT_locked));
+
nx = x - (1 | PGT_locked);
+ /* We must not drop the last reference here. */
+ ASSERT(nx & PGT_count_mask);
} while ( (y = cmpxchg(&page->u.inuse.type_info, x, nx)) != x );
}
@@ -2308,6 +2312,17 @@ static int _put_page_type(struct page_info *page, bool preemptible,
set_tlbflush_timestamp(page);
}
+ else if ( unlikely((nx & (PGT_locked | PGT_count_mask)) ==
+ (PGT_locked | 1)) )
+ {
+ /*
+ * We must not drop the second to last reference when the page is
+ * locked, as page_unlock() doesn't do any cleanup of the type.
+ */
+ cpu_relax();
+ y = page->u.inuse.type_info;
+ continue;
+ }
if ( likely((y = cmpxchg(&page->u.inuse.type_info, x, nx)) == x) )
break;
--
2.14.1
[-- Attachment #4: xsa242-4.9.patch --]
[-- Type: application/octet-stream, Size: 1459 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: don't allow page_unlock() to drop the last type reference
Only _put_page_type() does the necessary cleanup, and hence not all
domain pages can be released during guest cleanup (leaving around
zombie domains) if we get this wrong.
This is XSA-242.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1923,7 +1923,11 @@ void page_unlock(struct page_info *page)
do {
x = y;
+ ASSERT((x & PGT_count_mask) && (x & PGT_locked));
+
nx = x - (1 | PGT_locked);
+ /* We must not drop the last reference here. */
+ ASSERT(nx & PGT_count_mask);
} while ( (y = cmpxchg(&page->u.inuse.type_info, x, nx)) != x );
}
@@ -2611,6 +2615,17 @@ static int _put_page_type(struct page_in
(page->count_info & PGC_page_table)) )
page_set_tlbflush_timestamp(page);
}
+ else if ( unlikely((nx & (PGT_locked | PGT_count_mask)) ==
+ (PGT_locked | 1)) )
+ {
+ /*
+ * We must not drop the second to last reference when the page is
+ * locked, as page_unlock() doesn't do any cleanup of the type.
+ */
+ cpu_relax();
+ y = page->u.inuse.type_info;
+ continue;
+ }
if ( likely((y = cmpxchg(&page->u.inuse.type_info, x, nx)) == x) )
break;
[-- Attachment #5: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
reply other threads:[~2017-10-18 12:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1e4n9I-0001M6-06@xenbits.xenproject.org \
--to=security@xen.org \
--cc=oss-security@lists.openwall.com \
--cc=security-team-members@xen.org \
--cc=xen-announce@lists.xen.org \
--cc=xen-devel@lists.xen.org \
--cc=xen-users@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).