Bug 19901 - xen security issues
Summary: xen security issues
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: advisory MGA5-64-OK
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2016-12-06 13:06 CET by Thomas Backlund
Modified: 2017-01-09 21:30 CET (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Thomas Backlund 2016-12-06 13:06:41 CET
Xen 4.5.5 + some additional security fixes currently building...

I'll fix up cauldron package soon-ish

CVE LIST:

CVE-2014-3672
CVE-2016-3158
CVE-2016-3159
CVE-2016-3710
CVE-2016-3712
CVE-2016-3960
CVE-2016-4962
CVE-2016-4963
CVE-2016-4480
CVE-2016-5242
CVE-2016-5403
CVE-2016-6258
CVE-2016-6259
CVE-2016-7092
CVE-2016-7093
CVE-2016-7094
CVE-2016-7777
CVE-2016-9377
CVE-2016-9378
CVE-2016-9379
CVE-2016-9380
CVE-2016-9381
CVE-2016-9382
CVE-2016-9383
CVE-2016-9384
CVE-2016-9385
CVE-2016-9386
CVE-2016-9637


SRPMS:
xen-4.5.5-1.mga5.src.rpm


i586:
libxen3.0-4.5.5-1.mga5.i586.rpm
libxen-devel-4.5.5-1.mga5.i586.rpm
ocaml-xen-4.5.5-1.mga5.i586.rpm
ocaml-xen-devel-4.5.5-1.mga5.i586.rpm
xen-4.5.5-1.mga5.i586.rpm
xen-doc-4.5.5-1.mga5.i586.rpm
xen-hypervisor-4.5.5-1.mga5.i586.rpm


x86_64:
lib64xen3.0-4.5.5-1.mga5.x86_64.rpm
lib64xen-devel-4.5.5-1.mga5.x86_64.rpm
ocaml-xen-4.5.5-1.mga5.x86_64.rpm
ocaml-xen-devel-4.5.5-1.mga5.x86_64.rpm
xen-4.5.5-1.mga5.x86_64.rpm
xen-doc-4.5.5-1.mga5.x86_64.rpm
xen-hypervisor-4.5.5-1.mga5.x86_64.rpm


Advisory:
This xen update is based on upstream 4.5.5 maintenance release, and fixes
the following security issues:

The qemu implementation in libvirt before 1.3.0 and Xen allows local guest
OS users to cause a denial of service (host disk consumption) by writing to
stdout or stderr (CVE-2014-3672)

The xrstor function in arch/x86/xstate.c in Xen 4.x does not properly handle
writes to the hardware FSW.ES bit when running on AMD64 processors, which
allows local guest OS users to obtain sensitive register content information
from another guest by leveraging pending exception and mask bits. NOTE: this
vulnerability exists because of an incorrect fix for CVE-2013-2076
(CVE-2016-3158).

The fpu_fxrstor function in arch/x86/i387.c in Xen 4.x does not properly
handle writes to the hardware FSW.ES bit when running on AMD64 processors,
which allows local guest OS users to obtain sensitive register content
information from another guest by leveraging pending exception and mask
bits. NOTE: this vulnerability exists because of an incorrect fix for
CVE-2013-2076 (CVE-2016-3159).

The VGA module in QEMU improperly performs bounds checking on banked access
to video memory, which allows local guest OS administrators to execute
arbitrary code on the host by changing access modes after setting the bank
register, aka the "Dark Portal" issue (CVE-2016-3710).

Integer overflow in the VGA module in QEMU allows local guest OS users to
cause a denial of service (out-of-bounds read and QEMU process crash) by
editing VGA registers in VBE mode (CVE-2016-3712).

Integer overflow in the x86 shadow pagetable code in Xen allows local guest
OS users to cause a denial of service (host crash) or possibly gain
privileges by shadowing a superpage mapping (CVE-2016-3960).

The libxl device-handling in Xen 4.6.x and earlier allows local OS guest
administrators to cause a denial of service (resource consumption or
management facility confusion) or gain host OS privileges by manipulating
information in guest controlled areas of xenstore (CVE-2016-4962).

The libxl device-handling in Xen through 4.6.x allows local guest OS users
with access to the driver domain to cause a denial of service (management
tool confusion) by manipulating information in the backend directories in
xenstore (CVE-2016-4963).

The guest_walk_tables function in arch/x86/mm/guest_walk.c in Xen 4.6.x and
earlier does not properly handle the Page Size (PS) page table entry bit at
the L4 and L3 page table levels, which might allow local guest OS users to
gain privileges via a crafted mapping of memory (CVE-2016-4480).

The p2m_teardown function in arch/arm/p2m.c in Xen 4.4.x through 4.6.x allows
local guest OS users with access to the driver domain to cause a denial of
service (NULL pointer dereference and host OS crash) by creating concurrent
domains and holding references to them, related to VMID exhaustion
(CVE-2016-5242).

The virtqueue_pop function in hw/virtio/virtio.c in QEMU allows local guest
OS administrators to cause a denial of service (memory consumption and QEMU
process crash) by submitting requests without waiting for completion
(CVE-2016-5403).

The PV pagetable code in arch/x86/mm.c in Xen 4.7.x and earlier allows local
32-bit PV guest OS administrators to gain host OS privileges by leveraging
fast-paths for updating pagetable entries (CVE-2016-6258).

Xen 4.5.x through 4.7.x do not implement Supervisor Mode Access Prevention
(SMAP) whitelisting in 32-bit exception and event delivery, which allows
local 32-bit PV guest OS kernels to cause a denial of service (hypervisor
and VM crash) by triggering a safety check (CVE-2016-6259).

The get_page_from_l3e function in arch/x86/mm.c in Xen allows local 32-bit
PV guest OS administrators to gain host OS privileges via vectors related
to L3 recursive pagetables (CVE-2016-7092).

Xen 4.5.3, 4.6.3, and 4.7.x allow local HVM guest OS administrators to
overwrite hypervisor memory and consequently gain host OS privileges by
leveraging mishandling of instruction pointer truncation during emulation
(CVE-2016-7093).

Buffer overflow in Xen 4.7.x and earlier allows local x86 HVM guest OS
administrators on guests running with shadow paging to cause a denial of
service via a pagetable update (CVE-2016-7094).

Xen 4.7.x and earlier does not properly honor CR0.TS and CR0.EM, which
allows local x86 HVM guest OS users to read or modify FPU, MMX, or XMM
register state information belonging to arbitrary tasks on the guest by
modifying an instruction while the hypervisor is preparing to emulate it
(CVE-2016-7777).

When Xen emulates instructions which generate software interrupts it needs
to perform a privilege check involving an IDT lookup. This check is sometimes
erroneously conducted as if the IDT had the format for a 32-bit guest, when
in fact it is in the 64-bit format. Xen will then read the wrong part of the
IDT and interpret it in an unintended manner. An unprivileged guest user
program may be able to crash the guest (CVE-2016-9377).

When Xen emulates instructions which generate software interrupts, and
chooses to deliver the software interrupt, it may try to use the method
intended for injecting exceptions. This is incorrect, and results in a
guest crash (CVE-2016-9378).

pygrub supports a number of output formats. When the S-expression output
format is requested, putting string quotes and S-expressions in the 
bootloader configuration file can produce incorrect output. A malicious
guest administrator can obtain the contents of sensitive host files (an
information leak), or can cause files on the host to be removed, causing
a denial of service or in unusual cases privilegie escalation (CVE-2016-9379).

When the nul-delimited output format is requested, nul bytes in the
bootloader configuration file can produce an ambiguous or confusing output
file, which is interpreted by libxl in a vulnerable way. A malicious guest
administrator can obtain the contents of sensitive host files (an information
leak), or can cause files on the host to be removed, causing a denial of
service or in unusual cases privilegie escalation (CVE-2016-9380).

The compiler can emit optimizations in qemu which can lead to double fetch
vulnerabilities. Specifically data on the rings shared between qemu and the
hypervisor (which the guest under control can obtain mappings of) can be
fetched twice (during which time the guest can alter the contents) possibly
leading to arbitrary code execution in qemu. Malicious administrators can
exploit this vulnerability to take over the qemu process, elevating its
privilege to that of the qemu process. In a system not using a device model
stub domain (or other techniques for deprivileging qemu), malicious guest
administrators can thus elevate their privilege to that of the host
(CVE-2016-9381).

LDTR, just like TR, is purely a protected mode facility. Hence even when
switching to a VM86 mode task, LDTR loading needs to follow protected mode
semantics. This was violated by the code. On SVM (AMD hardware): a malicious
unprivileged guest process can escalate its privilege to that of the guest
operating system. On both SVM and VMX (Intel hardware): a malicious
unprivileged guest process can crash the guest (CVE-2016-9382).

The x86 instructions BT, BTC, BTR, and BTS, when used with a destination
memory operand and a source register rather than an immediate operand,
access a memory location offset from that specified by the memory operand
as specified by the high bits of the register source. When Xen needs to
emulate such an instruction, to efficiently handle the emulation, the memory
address and register operand are recalculated internally to Xen. In this
process, the high bits of an intermediate expression were discarded, leading
to both the memory location and the register operand being wrong. A malicious
guest can modify arbitrary memory, allowing for arbitrary code execution
(and therefore privilege escalation affecting the whole host), a crash of
the host (leading to a DoS), or information leaks (CVE-2016-9383).

Along with their main kernel binary, unprivileged guests may arrange to 
have their Xen environment load (kernel) symbol tables for their use.
The ELF image metadata created for this purpose has a few unused bytes
when the symbol table binary is in 32-bit ELF format. These unused bytes
were not properly cleared during symbol table loading. A malicious
unprivileged guest may be able to obtain sensitive information from the
host (CVE-2016-9384).

Both writes to the FS and GS register base MSRs as well as the WRFSBASE and
WRGSBASE instructions require their input values to be canonical, or a #GP
fault will be raised. When the use of those instructions by the hypervisor
was enabled, the previous guard against #GP faults (having recovery code
attached) was accidentally removed. A malicious guest administrator can
crash the host, leading to a DoS (CVE-2016-9385).

The Xen x86 emulator erroneously failed to consider the unusability of
segments when performing memory accesses. An unprivileged guest user
program may be able to elevate its privilege to that of the guest operating
system (CVE-2016-9386).


The code in qemu which implements ioport read/write looks up the specified
ioport address in a 32-bit dispatch table without proper range checks.
Xen will write only 16-bit address ioport accesses. However, depending on
the Xen and qemu version, the ring may be writeable by the guest. If so,
the guest can generate out-of-range ioport accesses, resulting in wild
pointer accesses within qemu. A malicious guest administrator can escalate
their privilege to that of the host (CVE-2016-9637).

For other fixes in this update, see the referenced changelogs.

References:
https://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-453.html
https://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-455.html
https://xenbits.xen.org/xsa/advisory-172.html
https://xenbits.xen.org/xsa/advisory-173.html
https://xenbits.xen.org/xsa/advisory-175.html
https://xenbits.xen.org/xsa/advisory-176.html
https://xenbits.xen.org/xsa/advisory-178.html
https://xenbits.xen.org/xsa/advisory-179.html
https://xenbits.xen.org/xsa/advisory-180.html
https://xenbits.xen.org/xsa/advisory-181.html
https://xenbits.xen.org/xsa/advisory-182.html
https://xenbits.xen.org/xsa/advisory-183.html
https://xenbits.xen.org/xsa/advisory-184.html
https://xenbits.xen.org/xsa/advisory-185.html
https://xenbits.xen.org/xsa/advisory-186.html
https://xenbits.xen.org/xsa/advisory-187.html
https://xenbits.xen.org/xsa/advisory-190.html
https://xenbits.xen.org/xsa/advisory-191.html
https://xenbits.xen.org/xsa/advisory-192.html
https://xenbits.xen.org/xsa/advisory-193.html
https://xenbits.xen.org/xsa/advisory-194.html
https://xenbits.xen.org/xsa/advisory-195.html
https://xenbits.xen.org/xsa/advisory-196.html
https://xenbits.xen.org/xsa/advisory-197.html
https://xenbits.xen.org/xsa/advisory-198.html
https://xenbits.xen.org/xsa/advisory-199.html
Dave Hodgins 2016-12-08 22:41:17 CET

CC: (none) => davidwhodgins
Whiteboard: (none) => advisory

Comment 1 Brian Rockwell 2016-12-10 17:15:32 CET
Interesting while installing x86_64 it also set the Kernel server 3.19.8.3 as well as 4.4.36.2 server.

Why?

I will continue forward.

CC: (none) => brtians1

Comment 2 Brian Rockwell 2016-12-10 17:22:24 CET
following process I used in https://bugs.mageia.org/show_bug.cgi?id=16956.  Except new kernel reference.  I'm running grub, will need to update for grub2.
Comment 3 Brian Rockwell 2016-12-10 17:39:40 CET
okay - I didn't like 3.19 running, so set up my grub - /boot/grub/menu.lst with this entry at the bottom.

title xen_server
kernel (hd0,4)/boot/xen.gz dom0_mem=4084M,max:6096M loglvl=all guest_loglvl=all
module (hd0,4)/boot/vmlinuz-4.4.36-server-2.mga5 BOOT_IMAGE=server_4.4.36-2.mga5 root=UUID=55e55dd4-5dfd-4eb4-ada5-79a63f006878 splash quiet noiswmd resume=UUID=24b4cd5a-0a6e-41a5-b02e-087f372f1783 vga=788
root (hd0,4)
module (hd0,4)/boot/initrd.img


rebooted and picked that option
# uname -a
Linux localhost 4.4.36-server-2.mga5 #1 SMP Tue Dec 6 17:32:56 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


# ps -ef | grep xen
root        21     2  0 16:30 ?        00:00:00 [xenwatch]
root        22     2  0 16:30 ?        00:00:00 [xenbus]
root        30     2  0 16:30 ?        00:00:00 [xenbus_frontend]
root       491     2  0 16:30 ?        00:00:00 [xen_pciback_wor]
root       948     1  0 16:30 ?        00:00:00 /usr/sbin/oxenstored --no-fork
root      1002     1  0 16:30 ?        00:00:00 /usr/sbin/xenconsoled --pid-file /var/run/xen/xenconsoled.pid --log=none --log-dir=/var/log/xen/console
root      1144     1  0 16:30 ?        00:00:00 /usr/libexec/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/xen/qemu-dom0.pid


Hurray it is running.

will try set up VM's now.
Comment 4 Brian Rockwell 2016-12-10 19:25:32 CET
I installed virt-manager and qemu.  Was able to run puppy linux as a VM


Works for me.

Whiteboard: advisory => advisory MGA5-64-OK

Comment 5 Brian Rockwell 2016-12-10 19:26:20 CET
taking away the validated-ok because it did pull in an old kernel as part of the install.  Let me know.

Whiteboard: advisory MGA5-64-OK => advisory

Brian Rockwell 2016-12-15 21:58:41 CET

Whiteboard: advisory => advisory feedback

Comment 6 Thomas Backlund 2017-01-05 19:35:37 CET
Changed the server deps and fixed 3 more security issues:

- x86 CMPXCHG8B emulation fails to ignore operand size override. A malicious
  unprivileged guest may be able to obtain sensitive information from the
  host (CVE-2016-9932).

- x86 PV guests may be able to mask interrupts. A malicious guest kernel
  administrator can cause a host hang or crash, resulting in a Denial of
  Service (CVE-2016-10024).

- x86: Mishandling of SYSCALL singlestep during emulation. Guest userspace
  which can invoke the instruction emulator can use this flaw to escalate
  its privilege to that of the guest kernel (CVE-2016-10013).


(advisory in svn updated)


new rpms to test:

SRPMS:
xen-4.5.5-1.1.mga5.src.rpm


i586:
libxen3.0-4.5.5-1.1.mga5.i586.rpm
libxen-devel-4.5.5-1.1.mga5.i586.rpm
ocaml-xen-4.5.5-1.1.mga5.i586.rpm
ocaml-xen-devel-4.5.5-1.1.mga5.i586.rpm
xen-4.5.5-1.1.mga5.i586.rpm
xen-doc-4.5.5-1.1.mga5.i586.rpm
xen-hypervisor-4.5.5-1.1.mga5.i586.rpm


x86_64:
lib64xen3.0-4.5.5-1.1.mga5.x86_64.rpm
lib64xen-devel-4.5.5-1.1.mga5.x86_64.rpm
ocaml-xen-4.5.5-1.1.mga5.x86_64.rpm
ocaml-xen-devel-4.5.5-1.1.mga5.x86_64.rpm
xen-4.5.5-1.1.mga5.x86_64.rpm
xen-doc-4.5.5-1.1.mga5.x86_64.rpm
xen-hypervisor-4.5.5-1.1.mga5.x86_64.rpm

Whiteboard: advisory feedback => advisory

Comment 7 Brian Rockwell 2017-01-06 17:53:11 CET
The following 38 packages are going to be installed:

- cyrus-sasl-2.1.26-10.mga5.x86_64
- glibc-devel-2.20-23.mga5.x86_64
- kernel-server-4.4.39-1.mga5-1-1.mga5.x86_64
- kernel-server-latest-4.4.39-1.mga5.x86_64
- kernel-userspace-headers-4.4.39-1.mga5.x86_64
- lib64aio1-0.3.110-3.mga5.x86_64
- lib64brlapi0.6-4.5-16.mga5.x86_64
- lib64bzip2-devel-1.0.6-7.1.mga5.x86_64
- lib64celt051_0-0.5.1.3-9.mga5.x86_64
- lib64gcrypt-devel-1.5.4-5.3.mga5.x86_64
- lib64gpg-error-devel-1.13-3.mga5.x86_64
- lib64lzma-devel-5.2.0-1.mga5.x86_64
- lib64nl-cli3_200-3.2.25-3.mga5.x86_64
- lib64nl-nf3_200-3.2.25-3.mga5.x86_64
- lib64nl-route3_200-3.2.25-3.mga5.x86_64
- lib64nl3-devel-3.2.25-3.mga5.x86_64
- lib64ossp_uuid-devel-1.6.2-12.mga5.x86_64
- lib64ossp_uuid16-1.6.2-12.mga5.x86_64
- lib64sasl2-plug-anonymous-2.1.26-10.mga5.x86_64
- lib64sasl2-plug-login-2.1.26-10.mga5.x86_64
- lib64sasl2-plug-plain-2.1.26-10.mga5.x86_64
- lib64spice-server1-0.12.5-2.3.mga5.x86_64
- lib64usbredirparser1-0.7-3.mga5.x86_64
- lib64vde3-2.3.2-11.mga5.x86_64
- lib64xen-devel-4.5.5-1.1.mga5.x86_64
- lib64xen3.0-4.5.5-1.1.mga5.x86_64
- lib64yajl-devel-2.0.4-5.mga5.x86_64
- lib64yajl2-2.0.4-5.mga5.x86_64
- lib64zlib-devel-1.2.8-7.1.mga5.x86_64
- ocaml-compiler-4.01.0-11.mga5.x86_64
- ocaml-xen-4.5.5-1.1.mga5.x86_64
- ocaml-xen-devel-4.5.5-1.1.mga5.x86_64
- qemu-2.4.1-7.mga5.x86_64
- qemu-img-2.4.1-7.mga5.x86_64
- systemd-devel-217-11.2.mga5.x86_64
- xen-4.5.5-1.1.mga5.x86_64
- xen-doc-4.5.5-1.1.mga5.x86_64
- xen-hypervisor-4.5.5-1.1.mga5.x86_64

304MB of additional disk space will be used.

96MB of packages will be retrieved.

Is it ok to continue?



title xen_server
kernel (hd0,4)/boot/xen.gz dom0_mem=4084M,max:6096M loglvl=all guest_loglvl=all
module (hd0,4)/boot/vmlinuz-4.4.39-server-1.mga5 BOOT_IMAGE=server_4.4.39-1.mga5 root=UUID=55e55dd4-5dfd-4eb4-ada5-79a63f006878 splash quiet noiswmd resume=UUID=24b4cd5a-0a6e-41a5-b02e-087f372f1783 vga=788
root (hd0,4)
module (hd0,4)/boot/initrd.img


rebooted â chose xen_server option

at terminal

[brian@localhost ~]$ ps -ef | grep xen
root        21     2  0 10:23 ?        00:00:00 [xenwatch]
root        22     2  0 10:23 ?        00:00:00 [xenbus]
root        30     2  0 10:23 ?        00:00:00 [xenbus_frontend]
root       504     2  0 10:23 ?        00:00:00 [xen_pciback_wor]
root       762     1  0 10:23 ?        00:00:00 /usr/sbin/oxenstored --no-fork
root       863     1  0 10:23 ?        00:00:00 /usr/sbin/xenconsoled --pid-file /var/run/xen/xenconsoled.pid --log=none --log-dir=/var/log/xen/console
root       973     1  0 10:23 ?        00:00:00 /usr/libexec/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/xen/qemu-dom0.pid

hurray â it's running.

Installing virt-manager

To satisfy dependencies, the following package(s) also need to be installed:

- gtk-vnc-i18n-0.5.3-6.mga5.noarch
- lib64cacard0-0.1.2-5.mga5.x86_64
- lib64gtk-vnc2.0_0-0.5.3-6.mga5.x86_64
- lib64gtkvnc-gir2.0-0.5.3-6.mga5.x86_64
- lib64gvnc-gir1.0-0.5.3-6.mga5.x86_64
- lib64gvnc1.0_0-0.5.3-6.mga5.x86_64
- lib64osinfo-gir1.0-0.2.11-5.mga5.x86_64
- lib64osinfo1.0_0-0.2.11-5.mga5.x86_64
- lib64spice-client-glib-gir2.0-0.25-5.mga5.x86_64
- lib64spice-client-glib2.0_8-0.25-5.mga5.x86_64
- lib64spice-client-gtk-gir3.0-0.25-5.mga5.x86_64
- lib64spice-client-gtk3.0_4-0.25-5.mga5.x86_64
- lib64usbredirhost1-0.7-3.mga5.x86_64
- lib64virt-glib-gir1.0-0.1.9-5.mga5.x86_64
- lib64virt-glib1.0_0-0.1.9-5.mga5.x86_64
- lib64virt0-1.2.9.3-1.4.mga5.x86_64
- lib64vte-gir2.91-0.38.3-1.mga5.x86_64
- lib64vte2.91_0-0.38.3-1.mga5.x86_64
- lib64xml2-gir2.0-1.42.0-3.mga5.x86_64
- libcacard-tools-0.1.2-5.mga5.x86_64
- libosinfo-common-0.2.11-5.mga5.x86_64
- python-curl-7.19.5-4.1.mga5.x86_64
- python-ipaddr-2.1.10-7.mga5.noarch
- python-libvirt-1.2.9-2.mga5.x86_64
- python-urlgrabber-3.10.1-5.mga5.noarch
- spice-gtk-0.25-5.mga5.x86_64
- vte3-0.38.3-1.mga5.x86_64
- vte3-profile-0.38.3-1.mga5.noarch

19MB of additional disk space will be used.

Had to add the following as well

The following 10 packages are going to be installed:

- augeas-lenses-1.2.0-3.mga5.x86_64
- dnsmasq-2.71-4.mga5.x86_64
- dnsmasq-base-2.71-4.mga5.x86_64
- ebtables-2.0.10.4-6.mga5.x86_64
- lib64augeas0-1.2.0-3.mga5.x86_64
- lib64fa1-1.2.0-3.mga5.x86_64
- lib64netcf1-0.2.8-1.mga5.x86_64
- libvirt-utils-1.2.9.3-1.4.mga5.x86_64
- netcat-openbsd-1.89-8.mga5.x86_64
- netcf-0.2.8-1.mga5.x86_64

39MB of additional disk space will be used.


Rebooted to bring in the services

I was able to spin up puppy linux in a VM.

Whiteboard: advisory => advisory MGA5-64-OK

Comment 8 Lewis Smith 2017-01-09 20:33:44 CET
Thank you Brian for your perseverence with Xen. Looking at Bug 16956 that you referenced, that was let out with just a 64-bit OK.
So validating this; advisory already in place for xen-4.5.5-1.1.mga5.src.rpm

Keywords: (none) => validated_update
CC: (none) => lewyssmith, sysadmin-bugs

Comment 9 Mageia Robot 2017-01-09 21:30:40 CET
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0012.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.