* Xen Security Advisory 10 - HVM guest user mode MMIO emulation DoS
@ 2012-07-26 15:30 Xen.org security team
[not found] ` <20497.25251.118584.533875-msK/Ju9w1zmnROeE8kUsYhEHtJm+Wo+I@public.gmane.org>
0 siblings, 1 reply; 2+ messages in thread
From: Xen.org security team @ 2012-07-26 15:30 UTC (permalink / raw)
To: xen-announce-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
oss-security-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1985 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory XSA-10
HVM guest user mode MMIO emulation DoS vulnerability
ISSUE DESCRIPTION
=================
Internal data of the emulator for MMIO operations may, under
certain rare conditions, at the end of one emulation cycle be left
in a state affecting a subsequent emulation such that this second
emulation would fail, causing an exception to be reported to the
guest kernel where none is expected.
IMPACT
======
Guest mode unprivileged (user) code, which has been granted
the privilege to access MMIO regions, may leverage that access
to crash the whole guest.
VULNERABLE SYSTEMS
==================
All HVM guests exposing MMIO ranges to unprivileged (user) mode.
All versions of Xen which support HVM guests are vulnerable to this issue.
MITIGATION
==========
This issue can be mitigated by running PV (para-virtualised)
guests only, or by ensuring (inside the guest) that MMIO regions
can be accessed only by trustworthy processes.
RESOLUTION
==========
Applying the appropriate attached patch will resolve the issue.
NOTE REGARDING CVE
==================
We do not yet have a CVE Candidate number for this vulnerability.
PATCH INFORMATION
=================
The attached patches resolve this issue
$ sha256sum xsa10-*.patch
f96b7849194901d7f663895f88c2ca4f4721559f1c1fe13bba515336437ab912 xsa10-4.x.patch
fb9dead017dfea99ad3e8d928582e67160c76518b7fe207d9a3324811baf06dd xsa10-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJQEWB0AAoJEIP+FMlX6CvZYhUH+wVPIAAfKPp5p5TYvY90nAbR
O427AbXKDD0Gval78ygQSIiQIrmP0l5MZdx/FsXfw5cXyNHWJDHrwzA9jXzfYeor
boFvYCjdgyeh6cBM7BR2OFgoB+v3KmMSZOSDfH87SYzZTpK1+2ImDgsoaI5cqUMN
x92bXzqohZhcG/5PBhdVaEdj3KTGCHZYwjieUdi5BbWsQry9Rzd7nV6TsRHAaBkW
+9s3XxtobMNMJyr2t7ZKO1YwfLSprpfFcZk4zfdLLFMBvvPoF7V+Pi3PJ+8S38QN
YcyhPoLgoTqSKZ7buyMux9JwSzn8yi4ETMHMTc3VGFQZQwnlNeMWVEUG2CiYVn8=
=H0Nc
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa10-unstable.patch --]
[-- Type: application/octet-stream, Size: 1086 bytes --]
x86/hvm: don't leave emulator in inconsistent state
The fact that handle_mmio(), and thus the instruction emulator, is
being run through twice for emulations that require involvement of the
device model, allows for the second run to see a different guest state
than the first one. Since only the MMIO-specific emulation routines
update the vCPU's io_state, if they get invoked on the second pass,
internal state (and particularly this variable) can be left in a state
making successful emulation of a subsequent MMIO operation impossible.
Consequently, whenever the emulator invocation returns without
requesting a retry of the guest instruction, reset io_state.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -179,6 +179,8 @@ int handle_mmio(void)
rc = hvm_emulate_one(&ctxt);
+ if ( rc != X86EMUL_RETRY )
+ vio->io_state = HVMIO_none;
if ( vio->io_state == HVMIO_awaiting_completion )
vio->io_state = HVMIO_handle_mmio_awaiting_completion;
else
[-- Attachment #3: xsa10-4.x.patch --]
[-- Type: application/octet-stream, Size: 1130 bytes --]
x86/hvm: don't leave emulator in inconsistent state
The fact that handle_mmio(), and thus the instruction emulator, is
being run through twice for emulations that require involvement of the
device model, allows for the second run to see a different guest state
than the first one. Since only the MMIO-specific emulation routines
update the vCPU's io_state, if they get invoked on the second pass,
internal state (and particularly this variable) can be left in a state
making successful emulation of a subsequent MMIO operation impossible.
Consequently, whenever the emulator invocation returns without
requesting a retry of the guest instruction, reset io_state.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -176,6 +176,8 @@ int handle_mmio(void)
rc = hvm_emulate_one(&ctxt);
+ if ( rc != X86EMUL_RETRY )
+ curr->arch.hvm_vcpu.io_state = HVMIO_none;
if ( curr->arch.hvm_vcpu.io_state == HVMIO_awaiting_completion )
curr->arch.hvm_vcpu.io_state = HVMIO_handle_mmio_awaiting_completion;
else
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-07-27 8:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-26 15:30 Xen Security Advisory 10 - HVM guest user mode MMIO emulation DoS Xen.org security team
[not found] ` <20497.25251.118584.533875-msK/Ju9w1zmnROeE8kUsYhEHtJm+Wo+I@public.gmane.org>
2012-07-27 8:10 ` Kurt Seifried
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).