linux-kernel - Re: [PATCH] KVM: ioapic: fix NULL deref ioapic->lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <be8045cc-a42c-b519-e4bf-e8c196429292@redhat.com>
Date:   Tue, 3 Jan 2017 13:06:18 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Wanpeng Li <kernellwp@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        KVM list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH] KVM: ioapic: fix NULL deref ioapic->lock


>>> Thanks, this is beautiful enough. :)
>>>
>>> Hmm, the combination of 6c7caebc26c5 ("KVM: introduce
>>> kvm->created_vcpus", 2016-06-16) and 4c5ea0a9cd02 ("locking/static_key:
>>> Fix concurrent static_key_slow_inc()", 2016-06-24) should have fixed it
>>> for good.
>>>
>>> Is the ENABLE_CAP necessary to reproduce?  Then, the bug is simply that
>>> the ENABLE_CAP should have failed without an irqchip (the
>>> KVM_CREATE_IRQCHIP in turn must have failed with EINVAL).
>>
>> ENABLE_CAP is necessary to reproduce.
>
> Now I see what Paolo means, how about something like below:
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 51ccfe0..7ec22e2 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3337,7 +3337,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct
> kvm_vcpu *vcpu,
>
>      switch (cap->cap) {
>      case KVM_CAP_HYPERV_SYNIC:
> -        return kvm_hv_activate_synic(vcpu);
> +        if (!irqchip_in_kernel(vcpu->kvm))
> +            return -EINVAL;
> +        else

You can simply drop the else and return directly.

Can't really say if this is the right fix, my first thought was that
a request has been set although it should never have been set for
that VCPU. Maybe that is an effect of synic being activated
(because synic code unconditionally later on sets the request).

Fixing the cause of the request seems better than fixing up the result.

-- 

David