All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot <syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com>,
	bp@alien8.de, brgerst@gmail.com, dave.hansen@linux.intel.com,
	hpa@zytor.com, kirill@shutemov.name,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	peterz@infradead.org, syzkaller-bugs@googlegroups.com,
	tglx@linutronix.de, thomas.lendacky@amd.com, x86@kernel.org
Subject: Re: [syzbot] BUG: unable to handle kernel paging request in get_desc
Date: Fri, 4 Nov 2022 18:41:01 +0000	[thread overview]
Message-ID: <Y2Vcvf2AiUJ5jCVf@google.com> (raw)
In-Reply-To: <CACT4Y+Y6A0wooT1ua9qcoGuRBV9nF5sfF4q3-tSs3y+AqnGvfA@mail.gmail.com>

On Fri, Nov 04, 2022, Dmitry Vyukov wrote:
> On Fri, 4 Nov 2022 at 10:39, 'Sean Christopherson' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> wrote:
> >
> > On Fri, Nov 04, 2022, Sean Christopherson wrote:
> > > On Fri, Nov 04, 2022, Dmitry Vyukov wrote:
> > > > On Fri, 4 Nov 2022 at 08:28, 'Sean Christopherson' via syzkaller-bugs
> > > > <syzkaller-bugs@googlegroups.com> wrote:
> > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com
> > > > > >
> > > > > > BUG: unable to handle page fault for address: fffffbc5a1c22e00
> > > > > > #PF: supervisor read access in kernel mode
> > > > > > #PF: error_code(0x0000) - not-present page
> > > > > > PGD 23ffe4067 P4D 23ffe4067 PUD 13ff2d067 PMD 13ff2c067 PTE 0
> > > > > > Oops: 0000 [#1] PREEMPT SMP KASAN
> > > > > > CPU: 0 PID: 5368 Comm: syz-executor.2 Not tainted 6.1.0-rc3-next-20221103-syzkaller #0
> > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
> > > > > > RIP: 0010:get_desc+0x128/0x460 arch/x86/lib/insn-eval.c:660
> > > > >
> > > > > I'm pretty sure this is the same thing as
> > > > >
> > > > >   BUG: unable to handle kernel paging request in vmx_handle_exit_irqoff
> > > > >
> > > > > I'll verify and get a patch posted shortly.
> > > >
> > > > This repro does not create any VMs, it's just:
> > > >
> > > > iopl(0x3)
> > > > rt_sigreturn()
> > > >
> > > > Do you still think it's related to the vmx_handle_exit_irqoff issue?
> > >
> > > Yes, the issue is that the shadow for the read-only IDT mapping in the CPU entry
> > > area isn't populated (commit 9fd429c28073 ("x86/kasan: Map shadow for percpu pages
> > > on demand") is to blame).  The bug manifests anytime software manually does an IDT
> > > lookup.
> >
> > Hrm, but the lookup is into the GDT, not the IDT, and I haven't been able to reproduce
> > this one.  I'll leave it open for now.
> 
> The repro calls rt_sigreturn() w/o actually setting up the signal
> frame (mcontext, etc). So I assume the kernel will restore completely
> bogus/random user-space mcontext. The data it reads from the stack may
> be uninit or depend on the compiler, etc.
> 
> As the result it should get completely random segment selector here:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/x86/lib/insn-eval.c?id=81214a573d19ae2fa5b528286ba23cd1cb17feec#n725
> 
> Can it be out-of-bounds or something?

The lookup is on CS.base (I trimmed the stack in my first reply) as part of the
IOPL emulation to see if userspace is attempting CLI or STI, so it's not related
to the sigframe.

  insn_get_seg_base arch/x86/lib/insn-eval.c:725 [inline]
  insn_get_effective_ip+0x187/0x1f0 arch/x86/lib/insn-eval.c:1476
  fixup_iopl_exception+0xd0/0x190 arch/x86/kernel/traps.c:627
  __exc_general_protection arch/x86/kernel/traps.c:752 [inline]
  exc_general_protection+0x176/0x210 arch/x86/kernel/traps.c:728
  asm_exc_general_protection+0x22/0x30 arch/x86/include/asm/idtentry.h:564
 RIP: 0003:0x7f250f3abf8c

It does look like some form out out-of-bounds selector though.  The offset in the
splat suggests CS.sel is something way above __USER_CS, which would explain why
insn_get_effective_ip() is doing a lookup in the first place (CS.base is assumed
to be 0 if userspace is in 64-bit mode, user_64bit_mode() is true if CS == __USER_CS)),
I just can't figure out how that tiny reproducer is getting a bad CS.  And the above
RIP strongly suggests userspace is indeed in 64-bit mode.

  reply	other threads:[~2022-11-04 18:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04 14:54 [syzbot] BUG: unable to handle kernel paging request in get_desc syzbot
2022-11-04 15:28 ` Sean Christopherson
2022-11-04 16:28   ` Dmitry Vyukov
2022-11-04 16:33     ` Sean Christopherson
2022-11-04 17:39       ` Sean Christopherson
2022-11-04 17:51         ` Dmitry Vyukov
2022-11-04 18:41           ` Sean Christopherson [this message]
2022-11-04 18:45             ` Dmitry Vyukov
2022-11-04 19:38               ` Sean Christopherson

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=Y2Vcvf2AiUJ5jCVf@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=hpa@zytor.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --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 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.