kernel/virt/kvm, branch linux-2.6.32.y

KVM: Improve create VCPU parameter (CVE-2013-4587)

2014-05-19T05:54:33Z

commit 338c7dbadd2671189cec7faf64c84d01071b3f96 upstream In multiple functions the vcpu_id is used as an offset into a bitfield. Ag malicious user could specify a vcpu_id greater than 255 in order to set or clear bits in kernel memory. This could be used to elevate priveges in the kernel. This patch verifies that the vcpu_id provided is less than 255. The api documentation already specifies that the vcpu_id must be less than max_vcpus, but this is currently not checked. Reported-by: Andrew Honig Cc: stable@vger.kernel.org Signed-off-by: Andrew Honig Signed-off-by: Paolo Bonzini Signed-off-by: Willy Tarreau

KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)

2013-06-10T09:42:38Z

commit a2c118bfab8bc6b8bb213abfc35201e441693d55 upstream. If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate that request. ioapic_read_indirect contains an ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in non-debug builds. In recent kernels this allows a guest to cause a kernel oops by reading invalid memory. In older kernels (pre-3.3) this allows a guest to read from large ranges of host memory. Tested: tested against apic unit tests. Signed-off-by: Andrew Honig Signed-off-by: Marcelo Tosatti Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

2012-10-07T21:37:24Z

commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream If some vcpus are created before KVM_CREATE_IRQCHIP, then irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading to potential NULL pointer dereferences. Fix by: - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP This is somewhat long winded because vcpu->arch.apic is created without kvm->lock held. Based on earlier patch by Michael Ellerman. Signed-off-by: Michael Ellerman Signed-off-by: Avi Kivity [dannf: backported to Debian's 2.6.32] Signed-off-by: Willy Tarreau

KVM: Device assignment permission checks

2012-10-07T21:37:19Z

commit 3d27e23b17010c668db311140b17bbbb70c78fb9 upstream Only allow KVM device assignment to attach to devices which: - Are not bridges - Have BAR resources (assume others are special devices) - The user has permissions to use Assigning a bridge is a configuration error, it's not supported, and typically doesn't result in the behavior the user is expecting anyway. Devices without BAR resources are typically chipset components that also don't have host drivers. We don't want users to hold such devices captive or cause system problems by fencing them off into an iommu domain. We determine "permission to use" by testing whether the user has access to the PCI sysfs resource files. By default a normal user will not have access to these files, so it provides a good indication that an administration agent has granted the user access to the device. [Yang Bai: add missing #include] [avi: fix comment style] Signed-off-by: Alex Williamson Signed-off-by: Yang Bai Signed-off-by: Marcelo Tosatti [dannf: backported to Debian's 2.6.32] Signed-off-by: Willy Tarreau

KVM: Remove ability to assign a device without iommu support

2012-10-07T21:37:18Z

commit 423873736b78f549fbfa2f715f2e4de7e6c5e1e9 upstream This option has no users and it exposes a security hole that we can allow devices to be assigned without iommu protection. Make KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option. Signed-off-by: Alex Williamson Signed-off-by: Marcelo Tosatti [dannf: backported to Debian's 2.6.32] Signed-off-by: Willy Tarreau

KVM: fix the handling of dirty bitmaps to avoid overflows

2010-04-26T14:41:37Z

(Cherry-picked from commit 87bf6e7de1134f48681fd2ce4b7c1ec45458cb6d) Int is not long enough to store the size of a dirty bitmap. This patch fixes this problem with the introduction of a wrapper function to calculate the sizes of dirty bitmaps. Note: in mark_page_dirty(), we have to consider the fact that __set_bit() takes the offset as int, not long. Signed-off-by: Takuya Yoshikawa Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman

KVM: only clear irq_source_id if irqchip is present

2010-01-28T23:02:50Z

commit e50212bb51356f0df48d6cce0aae5acf41df336d upstream. Otherwise kvm might attempt to dereference a NULL pointer. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: fix lock imbalance in kvm_*_irq_source_id()

2010-01-28T23:02:49Z

commit 0c6ddcebd8303ada6faefa6f72ac18b6230320c4 upstream. Stanse found 2 lock imbalances in kvm_request_irq_source_id and kvm_free_irq_source_id. They omit to unlock kvm->irq_lock on fail paths. Fix that by adding unlock labels at the end of the functions and jump there from the fail paths. Signed-off-by: Jiri Slaby Cc: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: only allow one gsi per fd

2010-01-28T23:02:43Z

commit f1d1c309f35e9b0fb961cffd70fbd04f450ec47c upstream. Looks like repeatedly binding same fd to multiple gsi's with irqfd can use up a ton of kernel memory for irqfd structures. A simple fix is to allow each fd to only trigger one gsi: triggering a storm of interrupts in guest is likely useless anyway, and we can do it by binding a single gsi to many interrupts if we really want to. Signed-off-by: Michael S. Tsirkin Acked-by: Acked-by: Gregory Haskins Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: fix irq_source_id size verification

2009-12-18T22:03:36Z

commit cd5a2685de4a642fd0bd763e8c19711ef08dbe27 upstream. find_first_zero_bit works with bit numbers, not bytes. Fixes https://sourceforge.net/tracker/?func=detail&aid=2847560&group_id=180599&atid=893831 Reported-by: "Xu, Jiajun" Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman