On 2011-12-14 16:51, Jan Kiszka wrote: > Failing to do this allowed user space to crash the host by creating a > PIT without in-kernel IRQ controllers and routes in place: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000128 > IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm] > ... > Call Trace: > [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm] > [<ffffffff81071431>] process_one_work+0x111/0x4d0 > [<ffffffff81071bb2>] worker_thread+0x152/0x340 > [<ffffffff81075c8e>] kthread+0x7e/0x90 > [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10 > > Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > --- > > Stable material as well. > > arch/x86/kvm/x86.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 23c93fe..7137a84 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3152,6 +3152,9 @@ long kvm_arch_vm_ioctl(struct file *filp, > goto out; > create_pit: > mutex_lock(&kvm->slots_lock); > + r = -ENXIO; > + if (!irqchip_in_kernel(kvm)) > + goto create_pit_unlock; > r = -EEXIST; > if (kvm->arch.vpit) > goto create_pit_unlock; Hmm, patch breaks existing qemu-kvm user space which creates the PIT before the irqchips these days. Too bad... We probably have to detect the inconsistency in place, i.e. when the PIT timer is about to be started. Hope that covers all cases. Need to check. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
