Re: kvm: GPF in kvm_lapic_latched_init

[Dmitry Vyukov <dvyukov@google.com>]

On Wed, Jun 22, 2016 at 10:46 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 22/06/2016 10:38, Dmitry Vyukov wrote:
>> On Wed, Jun 22, 2016 at 10:36 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> On 22/06/2016 10:20, Dmitry Vyukov wrote:
>>>>>>>> All crashes suggest that apic is NULL.
>>>>>>>>
>>>>>>>> On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6).
>>>>
>>>> Ping. Just hit it again on 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20):
>>>
>>> This might have been the same bug you reported yesterday in kvm_set_cr8.
>>>  I've sent a patch to fix static keys.
>>
>> Then it is probably the same as the following one as well?
>
> Not 100% sure, can you send the reproducer?


I can't directly reproduce this. When I tried I hit other known bugs, e.g.:

BUG: KASAN: use-after-free in do_raw_spin_lock+0x281/0x2b0 at addr
ffff8800606e0c64
Read of size 4 by task syz-executor/11240
page:ffffea000181b800 count:0 mapcount:-127 mapping:          (null) index:0x0
flags: 0x4fffe0000000000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 11240 Comm: syz-executor Tainted: G      D         4.7.0-rc4+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff880b58e0 ffff88004082f850 ffffffff82cc62cf ffffffff4082f8e0
 fffffbfff1016b1c ffff88004082f8e0 ffff8800606e0c64 ffff8800606e0c98
 ffff88006b31d6a8 ffff8800606e0c60 ffff88004082f8d0 ffffffff817bdfb2
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82cc62cf>] dump_stack+0x12e/0x18f lib/dump_stack.c:51
 [<     inline     >] print_address_description mm/kasan/report.c:191
 [<ffffffff817bdfb2>] kasan_report_error+0x4e2/0x510 mm/kasan/report.c:276
 [<     inline     >] kasan_report mm/kasan/report.c:298
 [<ffffffff817be09e>] __asan_report_load4_noabort+0x3e/0x40
mm/kasan/report.c:318
 [<     inline     >] debug_spin_lock_before kernel/locking/spinlock_debug.c:83
 [<ffffffff81484e81>] do_raw_spin_lock+0x281/0x2b0
kernel/locking/spinlock_debug.c:135
 [<     inline     >] __raw_spin_lock_irq include/linux/spinlock_api_smp.h:131
 [<ffffffff86a969ff>] _raw_spin_lock_irq+0x6f/0x80 kernel/locking/spinlock.c:167
 [<     inline     >] spin_lock_irq include/linux/spinlock.h:332
 [<ffffffff81073eff>] kvm_irqfd_release+0x2f/0x120
arch/x86/kvm/../../../virt/kvm/eventfd.c:584
 [<ffffffff8105dfca>] kvm_vm_release+0x3a/0x50
arch/x86/kvm/../../../virt/kvm/kvm_main.c:752
 [<ffffffff81819ee6>] __fput+0x236/0x780 fs/file_table.c:208
 [<ffffffff8181a4b5>] ____fput+0x15/0x20 fs/file_table.c:244
 [<ffffffff813d0826>] task_work_run+0xf6/0x170 kernel/task_work.c:115
 [<     inline     >] exit_task_work include/linux/task_work.h:21
 [<ffffffff8137aed2>] do_exit+0xa62/0x2c80 kernel/exit.c:748
 [<ffffffff8137d268>] do_group_exit+0x108/0x330 kernel/exit.c:878
 [<ffffffff813a0734>] get_signal+0x634/0x15e0 kernel/signal.c:2307
 [<ffffffff811fa943>] do_signal+0x83/0x1f20 arch/x86/kernel/signal.c:783
 [<ffffffff81006695>] exit_to_usermode_loop+0x1a5/0x210
arch/x86/entry/common.c:229
 [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:264
 [<ffffffff8100885f>] syscall_return_slowpath+0x2bf/0x340
arch/x86/entry/common.c:329
 [<ffffffff86a9709c>] entry_SYSCALL_64_fastpath+0xbf/0xc1
arch/x86/entry/entry_64.S:241


So probably it's induced by other bugs.


I've looked at preempt_notifier_inc/preempt_notifier_dec calls, but I
don't see any obvious bugs. I thought that maybe preempt_notifier_inc
is called after installing fd into the file table, in which case
another thread could do ioctl's on the fd before preempt_notifier_inc,
but it does not seem to be the case. dup calls should also be properly
handled, right?