OVMSA-2015-0142 - xen security update
| Type: | SECURITY |
| Severity: | IMPORTANT |
| Release Date: | 2015-10-29 |
Description
[4.1.3-25.el5.127.79]
- 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
Acked-by: Chuck Anderson
Reviewed-by: John Haxby [bug 22088956] {CVE-2015-7971}
[4.1.3-25.el5.127.78]
- xenoprof: free domain's vcpu array
This was overlooked in fb442e2171 ('x86_64: allow more vCPU-s per
guest').
This is XSA-151.
Signed-off-by: Jan Beulich
Reviewed-by: Ian Campbell
Acked-by: Chuck Anderson
Reviewed-by: John Haxby [bug 22088857] {CVE-2015-7969}
[4.1.3-25.el5.127.77]
- x86: guard against undue super page PTE creation
When optional super page support got added (commit bd1cd81d64 'x86: PV
support for hugepages'), two adjustments were missed: mod_l2_entry()
needs to consider the PSE and RW bits when deciding whether to use the
fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK
unconditionally.
This is XSA-148.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
[backport to Xen 4.1]
Signed-off-by: Andrew Cooper
Acked-by: Chuck Anderson
Reviewed-by: John Haxby [bug 22088420] {CVE-2015-7835}
[4.1.3-25.el5.127.76]
- VMX: fix PAT value seen by guest
The XSA-60 fixes introduced a window during which the guest PAT gets
forced to all zeros. This shouldn't be visible to the guest. Therefore
we need to intercept PAT MSR accesses during that time period.
Signed-off-by: Jan Beulich
Reviewed-by: Liu Jinsong
From fce79f8ce91dc45f3a4d699ee67c49e6cbeb1197
Signed-off-by: Zhenzhong Duan [bug 18325294]
[4.1.3-25.el5.127.75]
- VMX: fix cr0.cd handling
This patch solves XSA-60 security hole:
1. For guest w/o VT-d, and for guest with VT-d but snooped, Xen need
do nothing, since hardware snoop mechanism has ensured cache coherency.
2. For guest with VT-d but non-snooped, cache coherency can not be
guaranteed by h/w snoop, therefore it need emulate UC type to guest:
2.1). if it works w/ Intel EPT, set guest IA32_PAT fields as UC so that
guest memory type are all UC.
2.2). if it works w/ shadow, drop all shadows so that any new ones would
be created on demand w/ UC.
This patch also fix a bug of shadow cr0.cd setting. Current shadow has a
small window between cache flush and TLB invalidation, resulting in possilbe
cache pollution. This patch pause vcpus so that no vcpus context involved
into the window.
This is CVE-2013-2212 / XSA-60.
Signed-off-by: Liu Jinsong
Reviewed-by: Jan Beulich
Reviewed-by: Tim Deegan
Reviewed-by: Andrew Cooper
Acked-by: Jun Nakajima
Acked-by: Keir Fraser
master commit: 62652c00efa55fb45374bcc92f7d96fc411aebb2
master date: 2013-11-06 10:12:36 +0100
Signed-off-by: Zhenzhong Duan [bug 18325294] {CVE-2013-2212}
[4.1.3-25.el5.127.74]
- VMX: remove the problematic set_uc_mode logic
XSA-60 security hole comes from the problematic vmx_set_uc_mode.
This patch remove vmx_set_uc_mode logic, which will be replaced by
PAT approach at later patch.
This is CVE-2013-2212 / XSA-60.
Signed-off-by: Liu Jinsong
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Tim Deegan
Acked-by: Jun Nakajima
master commit: 1c84d046735102e02d2df454ab07f14ac51f235d
master date: 2013-11-06 10:12:00 +0100
Signed-off-by: Zhenzhong Duan [bug 18325294] {CVE-2013-2212}
[4.1.3-25.el5.127.73]
- VMX: disable EPT when !cpu_has_vmx_pat
Recently Oracle developers found a Xen security issue as DOS affecting,
named as XSA-60. Please refer http://xenbits.xen.org/xsa/advisory-60.html
Basically it involves how to handle guest cr0.cd setting, which under
some environment it consumes much time resulting in DOS-like behavior.
This is a preparing patch for fixing XSA-60. Later patch will fix XSA-60
via PAT under Intel EPT case, which depends on cpu_has_vmx_pat.
This is CVE-2013-2212 / XSA-60.
Signed-off-by: Liu Jinsong
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Tim Deegan
Acked-by: Jun Nakajima
master commit: c13b0d65ddedd74508edef5cd66defffe30468fc
master date: 2013-11-06 10:11:18 +0100
Signed-off-by: Zhenzhong Duan [bug 18325294] {CVE-2013-2212}
[4.1.3-25.el5.127.72]
- Fix save/restore of guest PAT table in HAP paging mode.
HAP paging mode guests use direct MSR read/write into the VMCS/VMCB
for the guest PAT table, while the current save/restore code was
accessing only the pat_cr field in hvm_vcpu, used when intercepting
the MSR mostly in shadow mode (the Intel scenario is a bit more
complicated). This patch fixes this issue creating a new couple of
hvm_funcs, get/set_guest_pat, that access the right PAT table based on
the paging mode and guest configuration.
Signed-off-by: Gianluca Guida
Acked-by: Tim Deegan
xen-unstable changeset: 25196:375fa55c7a6c
xen-unstable date: Tue Apr 17 07:29:26 UTC 2012
Prerequisite commit for XSA-60/CVE-2013-2212
Signed-off-by: Zhenzhong [bug 18325294]
[4.1.3-25.el5.127.71]
- x86/HVM: confine internally handled MMIO to solitary regions
While it is generally wrong to cross region boundaries when dealing
with MMIO accesses of repeated string instructions (currently only
MOVS) as that would do things a guest doesn't expect (leaving aside
that none of these regions would normally be accessed with repeated
string instructions in the first place), this is even more of a problem
for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
made dereference NULL 'entry' pointers this way) as well as undersized
(1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
space beyond the one memory page set up for holding LAPIC register
values).
Since those functions validly assume to be called only with addresses
their respective checking functions indicated to be okay, it is generic
code that needs to be fixed to clip the repetition count.
To be on the safe side (and consistent), also do the same for buffered
I/O intercepts, even if their only client (stdvga) doesn't put the
hypervisor at risk (i.e. 'only' guest misbehavior would result).
This is CVE-2014-8867 / XSA-112.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
master commit: c5397354b998d030b021810b8202de93b9526818
master date: 2014-11-27 14:01:40 +0100
Signed-off-by: Zhenzhong Duan
Reviewed-by: Konrad Rzeszutek Wilk [bug 20361799] {CVE-2014-8867}
[4.1.3-25.el5.127.70]
- x86/MCE: Fix race condition in mctelem_reserve
These lines (in mctelem_reserve)
newhead = oldhead->mcte_next;
if (cmpxchgptr(freelp, oldhead, newhead) == oldhead) {
are racy. After you read the newhead pointer it can happen that another
flow (thread or recursive invocation) change all the list but set head
with same value. So oldhead is the same as *freelp but you are setting
a new head that could point to whatever element (even already used).
This patch use instead a bit array and atomic bit operations.
Signed-off-by: Frediano Ziglio
Reviewed-by: Liu Jinsong
Upstream commit 60ea3a3ac3d2bcd8e85b250fdbfc46b3b9dc7085
Signed-off-by: Zhenzhong Duan
Acked-by: Joe Jin [bug 19613191]
[4.1.3-25.el5.127.69]
- mce: fix race condition in mctelem_xchg_head
The function (mctelem_xchg_head()) used to exchange mce telemetry
list heads is racy. It may write to the head twice, with the second
write linking to an element in the wrong state.
If there are two threads, T1 inserting on committed list; and T2
trying to consume it.
1. T1 starts inserting an element (A), sets prev pointer (mcte_prev).
2. T1 is interrupted after the cmpxchg succeeded.
3. T2 gets the list and changes element A and updates the commit list
head.
4. T1 resumes, reads pointer to prev again and compare with result
from the cmpxchg which succeeded but in the meantime prev changed
in memory.
5. T1 thinks the cmpxchg failed and goes around the loop again,
linking head to A again.
To solve the race use temporary variable for prev pointer.
*linkp (which point to a field in the element) must be updated before
the cmpxchg() as after a successful cmpxchg the element might be
immediately removed and reinitialized.
The wmb() prior to the cmpchgptr() call is not necessary since it is
already a full memory barrier. This wmb() is thus removed.
Signed-off-by: Frediano Ziglio
Reviewed-by: Liu Jinsong
Upstream commit e9af61b969906976188609379183cb304935f448
Signed-off-by: Zhenzhong Duan
Acked-by: Joe Jin [bug 19613191]
Related CVEs
Updated Packages
| Release/Architecture | Filename | MD5sum | Superseded By Advisory |
|
| Oracle VM 3.2 (x86_64) | xen-4.1.3-25.el5.127.79.src.rpm | 1113a6de07c96d24cba56f4c164a3506 | OVMSA-2021-0014 |
| xen-4.1.3-25.el5.127.79.x86_64.rpm | 923bc8efa83e8f05d437eea587ef49bf | OVMSA-2021-0014 |
| xen-devel-4.1.3-25.el5.127.79.x86_64.rpm | 41649879a3fea8f4b6c114a8fd353b6c | OVMSA-2019-0048 |
| xen-tools-4.1.3-25.el5.127.79.x86_64.rpm | b23bdfbd4af86a0c3ebfbd8726d46717 | OVMSA-2021-0014 |
This page is generated automatically and has not been checked for errors or omissions. For clarification
or corrections please contact the Oracle Linux ULN team
