linux-kernel - Re: [syzbot] BUG: unable to handle kernel paging request in get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+Y6A0wooT1ua9qcoGuRBV9nF5sfF4q3-tSs3y+AqnGvfA@mail.gmail.com>
Date:   Fri, 4 Nov 2022 10:51:30 -0700
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     syzbot <syzbot+ffb4f000dc2872c93f62@...kaller.appspotmail.com>,
        bp@...en8.de, brgerst@...il.com, dave.hansen@...ux.intel.com,
        hpa@...or.com, kirill@...temov.name, linux-kernel@...r.kernel.org,
        mingo@...hat.com, peterz@...radead.org,
        syzkaller-bugs@...glegroups.com, tglx@...utronix.de,
        thomas.lendacky@....com, x86@...nel.org
Subject: Re: [syzbot] BUG: unable to handle kernel paging request in get_desc

On Fri, 4 Nov 2022 at 10:39, 'Sean Christopherson' via syzkaller-bugs
<syzkaller-bugs@...glegroups.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@...glegroups.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@...kaller.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?