Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <00000000000035fba305eca64106@google.com> <Y2UvigDr9ctxlEEE@google.com>
 <CACT4Y+Zb0T4bPk=gzYtexPqHTGSFAHaeY6DCYq268GV4+TM+gQ@mail.gmail.com>
 <Y2U+8cM9z0axes2y@google.com> <Y2VOU96gcoor288M@google.com>
In-Reply-To: <Y2VOU96gcoor288M@google.com>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Fri, 4 Nov 2022 10:51:30 -0700
Message-ID: <CACT4Y+Y6A0wooT1ua9qcoGuRBV9nF5sfF4q3-tSs3y+AqnGvfA@mail.gmail.com>
Subject: Re: [syzbot] BUG: unable to handle kernel paging request in get_desc
To:     Sean Christopherson <seanjc@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
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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:
> > > >
> > > > On Fri, Nov 04, 2022, syzbot wrote:
> > > > > Hello,
> > > > >
> > > > > syzbot found the following issue on:
> > > > >
> > > > > HEAD commit:    81214a573d19 Add linux-next specific files for 20221103
> > > > > git tree:       linux-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=132019de880000
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=cdc625e9234bac0
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=ffb4f000dc2872c93f62
> > > > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12dd52ca880000
> > > > >
> > > > > Downloadable assets:
> > > > > disk image: https://storage.googleapis.com/syzbot-assets/5d4dda497754/disk-81214a57.raw.xz
> > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/9658efff160a/vmlinux-81214a57.xz
> > > > > kernel image: https://storage.googleapis.com/syzbot-assets/3711180f2565/bzImage-81214a57.xz
> > > > >
> > > > > 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?