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>
Subject: Re: [syzbot] upstream test error: KFENCE: use-after-free in kvm_fastop_exception
Date: Tue, 21 Sep 2021 23:34:09 +0000 [thread overview]
Message-ID: <YUpr8Vu8xqCDwkE8@google.com> (raw)
In-Reply-To: <CACT4Y+Y1c-kRk83M-qiFY40its+bP3=oOJwsbSrip5AB4vBnYA@mail.gmail.com>
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.
next prev parent reply other threads:[~2021-09-21 23:34 UTC|newest]
Thread overview: 9+ 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 11:04 ` Marco Elver
2021-09-17 12:43 ` Dmitry Vyukov
2021-09-21 23:34 ` Sean Christopherson [this message]
2021-09-27 14:16 ` Dmitry Vyukov
2021-09-27 16:07 ` Sean Christopherson
2021-09-27 23:45 ` Josh Poimboeuf
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=YUpr8Vu8xqCDwkE8@google.com \
--to=seanjc@google.com \
--cc=dvyukov@google.com \
--cc=elver@google.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=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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).