-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2015-3340 / XSA-132
                              version 3

             Information leak through XEN_DOMCTL_gettscinfo

UPDATES IN VERSION 3
====================

Fix patch name.

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

The handler for XEN_DOMCTL_gettscinfo failed to initialize a padding
field subsequently copied to guest memory.

(A similar bug existed in XEN_SYSCTL_getdomaininfolist, which is
addressed by the patches provided here even though that operation was
declared by XSA-77 not to provide security benefits if disaggregated.)

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 may be able to read sensitive data relating to the
hypervisor or other guests not under the control of that domain.

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

Xen 4.0.x and later are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

The vulnerability is only exposed to service domains with privilege over
another guest.  In a usual configuration that means only device model
emulators (qemu-dm) when these are running in a separate domain.

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

This vulnerability is applicable for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  In this case a guest which has already
exploited another vulnerability, to gain control of the device model,
would be able to exercise the information leak.

However, the security of a system with qemu-dm running in a stub domain
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.

Finally, in a radically disaggregated system, where the service domain
software (probably, the device model domain image in the HVM case) is
not always supplied by the host administrator, a malicious service
domain administrator can exercise this vulnerability.

MITIGATION
==========

There is no mitigation available.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability (so long as there isn't also a vulnerability in the
service domain).

NOTE REGARDING LACK OF EMBARGO
==============================

The fix for this bug was publicly posted on xen-devel, before it was
appreciated that there was a security problem.

CREDITS
=======

This issue was recognized as security issue by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa132.patch                 xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x
xsa132-4.2.patch             Xen 4.2.x

$ sha256sum xsa132*.patch
3a28eb33c02360ec22c51824e469b1cf6be87941256d0b3aa34a5bd1d7735328  xsa132-4.2.patch
329d4edf1e1133795ece41f2fc8887c5f4cc06b42ced63c810c610b17bcee46d  xsa132.patch
$
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b+0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZxa8H/RUnxTkP8oZ6E9FIY2IyxMuKKQwkT7QEzkjziTeU
Y1QkOc5skh8EnMBUQS3nok8ZcLpey5SvPeNI5rMzjDj0cNHz5F7yntqZF43gE6Gq
gC6P322WRWPrx6MmP0Azez90za40SuyMiA9oLXncCVs7rD4Qp1mn98hRzt9zELjD
BzLaqBSN1hwMCt8Scjb+ELNvCxprigCtudZ+OzR6cl3p7cuRNgs0KKtx7by7bXXk
2GivMZbUYLCdjdJIS8h2PJ20qEerlzBZNfvcazRjy6cN4KUswl+mGntWnBc7l1KZ
igqi8C0EJab20LeLISz4ow1i5MCqN54c5w0/mUKmxK5EVt0=
=l+Py
-----END PGP SIGNATURE-----