* Xen Security Advisory 104 (CVE-2014-7154) - Race condition in HVMOP_track_dirty_vram
@ 2014-09-24 10:30 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2014-09-24 10:30 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2014-7154 / XSA-104
version 3
Race condition in HVMOP_track_dirty_vram
UPDATES IN VERSION 3
====================
This issue has been assigned CVE-2014-7154.
ISSUE DESCRIPTION
=================
The routine controlling the setup of dirty video RAM tracking latches
the value of a pointer before taking the respective guarding lock, thus
making it possible for a stale pointer to be used by the time the lock
got acquired and the pointer gets dereferenced.
The hypercall providing access to the affected function is available to
the domain controlling HVM guests.
IMPACT
======
Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.
Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)
VULNERABLE SYSTEMS
==================
Xen versions from 4.0.0 onwards are vulnerable.
This vulnerability is only applicable to Xen systems using stub
domains or other forms of disaggregation of control domains for HVM
guests.
MITIGATION
==========
There is no mitigation available for this issue.
(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process. Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)
CREDITS
=======
This issue was discovered by Andrew Cooper at Citrix.
RESOLUTION
==========
Applying the attached patch resolves this issue.
xsa104.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x
$ sha256sum xsa104*.patch
fc02f6365ca79a6ef386c882b57fab8b56aa12b54fc9b05054552f0f25e32047 xsa104.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUIpziAAoJEIP+FMlX6CvZO2wIAMm2konqFYzaAZXbEH25T24K
aNTRF+x+RFwZy/701GupySti6Go6HPvm4uya09qIVRyTkafH2WF+VT93rBRlROHM
z5ZFwR/wKLFj3TPr/Fhb52ynwDdRPMvFkaWGxvSvxjASBbAPxCAlE8SuTmG1nBOe
RtnHNk6cxV5UeYTZ8TosG7RvlPIVA17o82btJ6DPbXIn2tENLTJaZf9cTtNZxKPo
kIEuo9E0JFQQyje+t7lImbMQbbe216JTRtATTivVuP68AcE/TSRggLwoBxSitjUp
YNbcfbHUeg2qltftvlZKeGgvrVceQ+Vj59cFNRj4r+xRXXywAAGZkgCpZNLeQnA=
=gwmy
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa104.patch --]
[-- Type: application/octet-stream, Size: 1651 bytes --]
x86/shadow: fix race condition sampling the dirty vram state
d->arch.hvm_domain.dirty_vram must be read with the domain's paging lock held.
If not, two concurrent hypercalls could both end up attempting to free
dirty_vram (the second of which will free a wild pointer), or both end up
allocating a new dirty_vram structure (the first of which will be leaked).
This is XSA-104.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3485,7 +3485,7 @@ int shadow_track_dirty_vram(struct domai
int flush_tlb = 0;
unsigned long i;
p2m_type_t t;
- struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+ struct sh_dirty_vram *dirty_vram;
struct p2m_domain *p2m = p2m_get_hostp2m(d);
if ( end_pfn < begin_pfn || end_pfn > p2m->max_mapped_pfn + 1 )
@@ -3495,6 +3495,8 @@ int shadow_track_dirty_vram(struct domai
p2m_lock(p2m_get_hostp2m(d));
paging_lock(d);
+ dirty_vram = d->arch.hvm_domain.dirty_vram;
+
if ( dirty_vram && (!nr ||
( begin_pfn != dirty_vram->begin_pfn
|| end_pfn != dirty_vram->end_pfn )) )
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -112,7 +112,7 @@ struct hvm_domain {
/* Memory ranges with pinned cache attributes. */
struct list_head pinned_cacheattr_ranges;
- /* VRAM dirty support. */
+ /* VRAM dirty support. Protect with the domain paging lock. */
struct sh_dirty_vram *dirty_vram;
/* If one of vcpus of this domain is in no_fill_mode or
[-- Attachment #3: 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:[~2014-09-24 10:30 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-24 10:30 Xen Security Advisory 104 (CVE-2014-7154) - Race condition in HVMOP_track_dirty_vram 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).