[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+Y0d4O3Mgz5fH1nCWdoFOstWPmaRixavb4hfjqOuwhGrg@mail.gmail.com>
Date: Tue, 5 Jun 2018 10:16:28 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: syzbot <syzbot+a1264132fc103340628f@...kaller.appspotmail.com>,
Radim Krčmář <rkrcmar@...hat.com>,
KVM list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: KASAN: use-after-free Read in do_general_protection
On Mon, May 28, 2018 at 1:25 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 26/05/2018 11:29, Dmitry Vyukov wrote:
>> KASAN: stack-out-of-bounds Read in do_general_protection
>> KASAN: slab-out-of-bounds Read in vmx_vcpu_run
>> KASAN: use-after-scope Read in vmx_vcpu_run
>> KASAN: stack-out-of-bounds Write in notify_die
>>
>> See full info at:
>> https://syzkaller.appspot.com/bug?extid=a1264132fc103340628f
>>
>>
>> There seems to be 2 problems:
>>
>> 1. msr_write_intercepted doing something notoriously bad.
>
> The faulting line is
>
> msr_bitmap = to_vmx(vcpu)->loaded_vmcs->msr_bitmap;
>
> so I suppose to_vmx(vcpu)->loaded_vmcs is bogus? That seems like "just"
> a corruption of the struct kvm_vcpu, because the loaded_vmcs field is
> pointing elsewhere inside the same struct.
This is reproducible and the reproducer only uses KVM syscalls. So it
seems that KVM corrupts itself. Perhaps it's KVM_SET_MSRS that messes
things?
Powered by blists - more mailing lists