SCIENTIFIC-LINUX-ERRATA Archives

December 2010

SCIENTIFIC-LINUX-ERRATA@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Tue, 21 Dec 2010 10:42:43 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (64 lines)
Synopsis:	Low: kvm security and bug fix update
Issue date:	2010-12-20
CVE Names:	CVE-2010-3881

It was found that some structure padding and reserved fields in certain
data structures in QEMU-KVM were not initialized properly before being
copied to user-space. A privileged host user with access to "/dev/kvm"
could use this flaw to leak kernel stack memory to user-space.
(CVE-2010-3881)

This update also fixes the following bugs:

* The 'kvm_amd' kernel module did not initialize the TSC (Time Stamp
Counter) offset in the VMCB (Virtual Machine Control Block) correctly.
After a vCPU (virtual CPU) has been created, the TSC offset in the VMCB
should have a negative value so that the virtual machine will see TSC
values starting at zero. However, the TSC offset was set to zero and
therefore the virtual machine saw the same TSC value as the host. With 
this update, the TSC offset has been updated to show the correct values.
(BZ#656984)

* Setting the boot settings of a virtual machine to, firstly, boot from 
PXE and, secondly, to boot from the hard drive would result in a PXE 
boot loop, that is, the virtual machine would not continue to boot from 
the hard drive if the PXE boot failed. This was caused by a flaw in the 
'bochs-bios' (part of KVM) code. With this update, after a virtual 
machine tries to boot from PXE and fails, it continues to boot from a 
hard drive if there is one present. (BZ#659850)

* If a 64-bit Scientific Linux 5.5 virtual machine was migrated to
another host with a different CPU clock speed, the clock of that virtual
machine would consistently lose or gain time (approximately half a 
second for every second the host is running). On machines that do not 
use the kvm clock, the network time protocol daemon (ntpd) could correct 
the time drifts caused by migration. However, using the pvclock caused 
the time to change consistently. This was due to flaws in the save/load 
functions of pvclock. With this update, the issue has been fixed and 
migrating a virtual machine no longer causes time drift. (BZ#660239)

The following procedure must be performed before this update will take
effect:

1) Stop all KVM guest virtual machines.

2) Either reboot the hypervisor machine or, as the root user, remove 
(using "modprobe -r [module]") and reload (using "modprobe [module]") 
all of the following modules which are currently running (determined 
using "lsmod"): kvm, ksm, kvm-intel or kvm-amd.

3) Restart the KVM guest virtual machines.

SL 5.x

     SRPMS:
kvm-83-164.el5_5.30.src.rpm
     x86_64:
kmod-kvm-83-164.el5_5.30.x86_64.rpm
kvm-83-164.el5_5.30.x86_64.rpm
kvm-qemu-img-83-164.el5_5.30.x86_64.rpm
kvm-tools-83-164.el5_5.30.x86_64.rpm

-Connie Sieh
-Troy Dawson

ATOM RSS1 RSS2