[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 152 (CVE-2015-7971) - x86: some pmu and profiling hypercalls lo
From: Xen.org security team <security () xen ! org>
Date: 2015-10-29 12:00:44
Message-ID: E1Zrlsq-00029M-TQ () xenbits ! xen ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2015-7971 / XSA-152
version 3
x86: some pmu and profiling hypercalls log without rate limiting
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
HYPERCALL_xenoprof_op and HYPERVISOR_xenpmu_op log some errors and
attempts at invalid operations.
These log messages are not rate-limited, even though they can be
triggered by guests.
IMPACT
======
A malicious guest could cause repeated logging to the hypervisor
console, leading to a Denial of Service attack.
VULNERABLE SYSTEMS
==================
Xen versions 3.2.x and later are affected. (The VPMU part of the
vulnerability is applicable only to Xen 4.6 and later.)
ARM systems are not affected. (The pmu hypercall is x86-specific, and
xenoprof is not supported on ARM.)
MITIGATION
==========
The problematic log messages are issued with priority Warning.
Therefore they can be rate limited by adding "loglvl=error/warning" to
the hypervisor command line or suppressed entirely by adding
"loglvl=error".
On systems where the guest kernel is controlled by the host rather
than guest administrator, running only kernels which do not call these
hypercalls will also prevent untrusted guest users from exploiting
this issue. However untrusted guest administrators can still trigger
it unless further steps are taken to prevent them 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.
xsa152-unstable.patch xen-unstable, Xen 4.6.x
xsa152-4.5.patch Xen 4.5.x, Xen 4.4.x, Xen 4.3.x
$ sha256sum xsa152*.patch
596f51797aa591b5abd068ead03e21215cf70997c98a4a562392499afe47b81c xsa152.patch
7ae2811ea80da29ee234ad5a2cbb5908e03db8fb6c50774d378d77d273e74e39 xsa152-4.5.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.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJWMgm/AAoJEIP+FMlX6CvZzPwIAJs/NTew5AJA3bTO6QZtVC2T
sRt2F11prjjeklrAcqSC03q2bBpyylLB6PJ1jmmtT0MKtST5BszGA+sJt3G8nxw1
XKN8zNX5Yzfmltgi6ZeWk/1ps6kceb4evhkIUzt1v8Ttge148rEedGrJD9eLeRht
XdZr8ujXwP3NGBAesKNf0DugPTR7diYyUzvwven+OXVPg0ZT53t1r6Xref7Vl4p6
5b9uOK3rh/QVRbPGTOA1vzObk0MssBTGA615JGG0da4fr4vVUQsVK/MV/N6oc4fJ
iUHUcH83ldLGB9kt3+kq1S6KBESInriytPrKxNFvaKOrPlaOTOKRGvJSW0QZpos=
=BsWE
-----END PGP SIGNATURE-----
["xsa152.patch" (application/octet-stream)]
x86: rate-limit logging in do_xen{oprof,pmu}_op()
Some of the sub-ops are acessible to all guests, and hence should be
rate-limited. In the xenoprof case, just like for XSA-146, include them
only in debug builds. Since the vPMU code is rather new, allow them to
be always present, but downgrade them to (rate limited) guest messages.
This is XSA-152.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -682,8 +682,8 @@ long do_xenpmu_op(unsigned int op, XEN_G
vpmu_mode = pmu_params.val;
else if ( vpmu_mode != pmu_params.val )
{
- printk(XENLOG_WARNING
- "VPMU: Cannot change mode while active VPMUs exist\n");
+ gprintk(XENLOG_WARNING,
+ "VPMU: Cannot change mode while active VPMUs exist\n");
ret = -EBUSY;
}
@@ -714,8 +714,8 @@ long do_xenpmu_op(unsigned int op, XEN_G
vpmu_features = pmu_params.val;
else
{
- printk(XENLOG_WARNING "VPMU: Cannot change features while"
- " active VPMUs exist\n");
+ gprintk(XENLOG_WARNING,
+ "VPMU: Cannot change features while active VPMUs exist\n");
ret = -EBUSY;
}
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -676,15 +676,13 @@ ret_t do_xenoprof_op(int op, XEN_GUEST_H
if ( (op < 0) || (op > XENOPROF_last_op) )
{
- printk("xenoprof: invalid operation %d for domain %d\n",
- op, current->domain->domain_id);
+ gdprintk(XENLOG_DEBUG, "invalid operation %d\n", op);
return -EINVAL;
}
if ( !NONPRIV_OP(op) && (current->domain != xenoprof_primary_profiler) )
{
- printk("xenoprof: dom %d denied privileged operation %d\n",
- current->domain->domain_id, op);
+ gdprintk(XENLOG_DEBUG, "denied privileged operation %d\n", op);
return -EPERM;
}
@@ -907,8 +905,7 @@ ret_t do_xenoprof_op(int op, XEN_GUEST_H
spin_unlock(&xenoprof_lock);
if ( ret < 0 )
- printk("xenoprof: operation %d failed for dom %d (status : %d)\n",
- op, current->domain->domain_id, ret);
+ gdprintk(XENLOG_DEBUG, "operation %d failed: %d\n", op, ret);
return ret;
}
["xsa152-4.5.patch" (application/octet-stream)]
x86: rate-limit logging in do_xen{oprof,pmu}_op()
Some of the sub-ops are acessible to all guests, and hence should be
rate-limited. In the xenoprof case, just like for XSA-146, include them
only in debug builds. Since the vPMU code is rather new, allow them to
be always present, but downgrade them to (rate limited) guest messages.
This is XSA-152.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -676,15 +676,13 @@ ret_t do_xenoprof_op(int op, XEN_GUEST_H
if ( (op < 0) || (op > XENOPROF_last_op) )
{
- printk("xenoprof: invalid operation %d for domain %d\n",
- op, current->domain->domain_id);
+ gdprintk(XENLOG_DEBUG, "invalid operation %d\n", op);
return -EINVAL;
}
if ( !NONPRIV_OP(op) && (current->domain != xenoprof_primary_profiler) )
{
- printk("xenoprof: dom %d denied privileged operation %d\n",
- current->domain->domain_id, op);
+ gdprintk(XENLOG_DEBUG, "denied privileged operation %d\n", op);
return -EPERM;
}
@@ -907,8 +905,7 @@ ret_t do_xenoprof_op(int op, XEN_GUEST_H
spin_unlock(&xenoprof_lock);
if ( ret < 0 )
- printk("xenoprof: operation %d failed for dom %d (status : %d)\n",
- op, current->domain->domain_id, ret);
+ gdprintk(XENLOG_DEBUG, "operation %d failed: %d\n", op, ret);
return ret;
}
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic