From: Sean Christopherson <seanjc@google.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com>, syzbot <syzbot+d08efd12a2905a344291@syzkaller.appspotmail.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk, the arch/x86 maintainers <x86@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, kasan-dev <kasan-dev@googlegroups.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Peter Zijlstra <peterz@infradead.org> Subject: Re: [syzbot] upstream test error: KFENCE: use-after-free in kvm_fastop_exception Date: Mon, 27 Sep 2021 16:07:51 +0000 [thread overview] Message-ID: <YVHsV+o7Ez/+arUp@google.com> (raw) In-Reply-To: <CACT4Y+YuX3sVQ5eHYzDJOtenHhYQqRsQZWJ9nR0sgq3s64R=DA@mail.gmail.com> +Josh and PeterZ On Mon, Sep 27, 2021, Dmitry Vyukov wrote: > On Wed, 22 Sept 2021 at 01:34, 'Sean Christopherson' via > syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > > > On Fri, Sep 17, 2021, Dmitry Vyukov wrote: > > > On Fri, 17 Sept 2021 at 13:04, Marco Elver <elver@google.com> wrote: > > > > > So it looks like in both cases the top fault frame is just wrong. But > > > > > I would assume it's extracted by arch-dependent code, so it's > > > > > suspicious that it affects both x86 and arm64... > > > > > > > > > > Any ideas what's happening? > > > > > > > > My suspicion for the x86 case is that kvm_fastop_exception is related > > > > to instruction emulation and the fault occurs in an emulated > > > > instruction? > > > > > > Why would the kernel emulate a plain MOV? > > > 2a: 4c 8b 21 mov (%rcx),%r12 > > > > > > And it would also mean a broken unwind because the emulated > > > instruction is in __d_lookup, so it should be in the stack trace. > > > > kvm_fastop_exception is a red herring. It's indeed related to emulation, and > > while MOV emulation is common in KVM, that emulation is for KVM guests not for > > the host kernel where this splat occurs (ignoring the fact that the "host" is > > itself a guest). > > > > kvm_fastop_exception is out-of-line fixup, and certainly shouldn't be reachable > > via d_lookup. It's also two instruction, XOR+RET, neither of which are in the > > code stream. > > > > IIRC, the unwinder gets confused when given an IP that's in out-of-line code, > > e.g. exception fixup like this. If you really want to find out what code blew > > up, you might be able to objdump -D the kernel and search for unique, matching > > disassembly, e.g. find "jmpq 0xf86d288c" and go from there. > > Hi Sean, > > Thanks for the info. > > I don't want to find out what code blew (it's __d_lookup). > I am interested in getting the unwinder fixed to output truthful and > useful frames. I was asking about the exact location to confirm that the explosion is indeed from exception fixup, which is the "unwinder scenario get confused" I was thinking of. Based on the disassembly from syzbot, that does indeed appear to be the case here, i.e. this 2a: 4c 8b 21 mov (%rcx),%r12 is from exception fixup from somewhere in __d_lookup (can't tell exactly what it's from, maybe KASAN?). > Is there more info on this "the unwinder gets confused"? Bug filed > somewhere or an email thread? Is it on anybody's radar? I don't know if there's a bug report or if this is on anyone's radar. The issue I've encountered in the past, and what I'm pretty sure is being hit here, is that the ORC unwinder doesn't play nice with out-of-line fixup code, presumably because there are no tables for the fixup. I believe kvm_fastop_exception() gets blamed because it's the first label that's found when searching back through the tables.
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com>, syzbot <syzbot+d08efd12a2905a344291@syzkaller.appspotmail.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk, the arch/x86 maintainers <x86@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, kasan-dev <kasan-dev@googlegroups.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Peter Zijlstra <peterz@infradead.org> Subject: Re: [syzbot] upstream test error: KFENCE: use-after-free in kvm_fastop_exception Date: Mon, 27 Sep 2021 16:07:51 +0000 [thread overview] Message-ID: <YVHsV+o7Ez/+arUp@google.com> (raw) In-Reply-To: <CACT4Y+YuX3sVQ5eHYzDJOtenHhYQqRsQZWJ9nR0sgq3s64R=DA@mail.gmail.com> +Josh and PeterZ On Mon, Sep 27, 2021, Dmitry Vyukov wrote: > On Wed, 22 Sept 2021 at 01:34, 'Sean Christopherson' via > syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > > > On Fri, Sep 17, 2021, Dmitry Vyukov wrote: > > > On Fri, 17 Sept 2021 at 13:04, Marco Elver <elver@google.com> wrote: > > > > > So it looks like in both cases the top fault frame is just wrong. But > > > > > I would assume it's extracted by arch-dependent code, so it's > > > > > suspicious that it affects both x86 and arm64... > > > > > > > > > > Any ideas what's happening? > > > > > > > > My suspicion for the x86 case is that kvm_fastop_exception is related > > > > to instruction emulation and the fault occurs in an emulated > > > > instruction? > > > > > > Why would the kernel emulate a plain MOV? > > > 2a: 4c 8b 21 mov (%rcx),%r12 > > > > > > And it would also mean a broken unwind because the emulated > > > instruction is in __d_lookup, so it should be in the stack trace. > > > > kvm_fastop_exception is a red herring. It's indeed related to emulation, and > > while MOV emulation is common in KVM, that emulation is for KVM guests not for > > the host kernel where this splat occurs (ignoring the fact that the "host" is > > itself a guest). > > > > kvm_fastop_exception is out-of-line fixup, and certainly shouldn't be reachable > > via d_lookup. It's also two instruction, XOR+RET, neither of which are in the > > code stream. > > > > IIRC, the unwinder gets confused when given an IP that's in out-of-line code, > > e.g. exception fixup like this. If you really want to find out what code blew > > up, you might be able to objdump -D the kernel and search for unique, matching > > disassembly, e.g. find "jmpq 0xf86d288c" and go from there. > > Hi Sean, > > Thanks for the info. > > I don't want to find out what code blew (it's __d_lookup). > I am interested in getting the unwinder fixed to output truthful and > useful frames. I was asking about the exact location to confirm that the explosion is indeed from exception fixup, which is the "unwinder scenario get confused" I was thinking of. Based on the disassembly from syzbot, that does indeed appear to be the case here, i.e. this 2a: 4c 8b 21 mov (%rcx),%r12 is from exception fixup from somewhere in __d_lookup (can't tell exactly what it's from, maybe KASAN?). > Is there more info on this "the unwinder gets confused"? Bug filed > somewhere or an email thread? Is it on anybody's radar? I don't know if there's a bug report or if this is on anyone's radar. The issue I've encountered in the past, and what I'm pretty sure is being hit here, is that the ORC unwinder doesn't play nice with out-of-line fixup code, presumably because there are no tables for the fixup. I believe kvm_fastop_exception() gets blamed because it's the first label that's found when searching back through the tables. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-27 16:08 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-04 18:58 [syzbot] upstream test error: KFENCE: use-after-free in kvm_fastop_exception syzbot 2021-09-17 10:00 ` Dmitry Vyukov 2021-09-17 10:00 ` Dmitry Vyukov 2021-09-17 11:04 ` Marco Elver 2021-09-17 11:04 ` Marco Elver 2021-09-17 12:43 ` Dmitry Vyukov 2021-09-17 12:43 ` Dmitry Vyukov 2021-09-21 23:34 ` Sean Christopherson 2021-09-21 23:34 ` Sean Christopherson 2021-09-27 14:16 ` Dmitry Vyukov 2021-09-27 14:16 ` Dmitry Vyukov 2021-09-27 16:07 ` Sean Christopherson [this message] 2021-09-27 16:07 ` Sean Christopherson 2021-09-27 23:45 ` Josh Poimboeuf 2021-09-27 23:45 ` Josh Poimboeuf 2021-09-28 10:16 ` Dmitry Vyukov 2021-09-28 10:16 ` Dmitry Vyukov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YVHsV+o7Ez/+arUp@google.com \ --to=seanjc@google.com \ --cc=dvyukov@google.com \ --cc=elver@google.com \ --cc=jpoimboe@redhat.com \ --cc=kasan-dev@googlegroups.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=peterz@infradead.org \ --cc=syzbot+d08efd12a2905a344291@syzkaller.appspotmail.com \ --cc=syzkaller-bugs@googlegroups.com \ --cc=viro@zeniv.linux.org.uk \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.