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 19:38:48 +0000	[thread overview]
Message-ID: <Y2VqSBWY/xGM/HBF@google.com> (raw)
In-Reply-To: <CACT4Y+ZUiiKNH56QM-JAy0ykh1fJ+CJ-k-aMcWD1euTbviKcwQ@mail.gmail.com>

On Fri, Nov 04, 2022, Dmitry Vyukov wrote:
> On Fri, 4 Nov 2022 at 11:41, Sean Christopherson <seanjc@google.com> wrote:
> >
> > 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:
> > > 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.
> 
> My understanding is that rt_sigreturn() restores complete user context
> from the info stored on the stack.
> Normally signal delivery will store that info on the stack first. But
> in this case there is no signal delivery, so rt_sigreturn() reads
> complete garbage from the stack and restores it into the context. I
> assume this can setup any non-sense CS and maybe even pretend this is
> not normal x86_64 mode (?).

Ha!  Indeed, shoving a sigcontext onto the stack that's valid enough to pass
basic checks but throws in a bad CS does the trick.

int main(void)
{
  struct sigcontext regs;
  
  syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
  syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
  syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
  syscall(__NR_iopl, 3);

  memset(&regs, 0, sizeof(regs));
  regs.cs = 0x1d0;
  syscall(__NR_rt_sigreturn);
  return 0;
}

Same root cause, different fix.  I'll post officially in a bit.

diff --git a/arch/x86/mm/cpu_entry_area.c b/arch/x86/mm/cpu_entry_area.c
index dff9001e5e12..4a6440461c10 100644
--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -195,7 +195,7 @@ static void __init setup_cpu_entry_area(unsigned int cpu)
        pgprot_t tss_prot = PAGE_KERNEL;
 #endif
 
-       cea_set_pte(&cea->gdt, get_cpu_gdt_paddr(cpu), gdt_prot);
+       cea_map_percpu_pages(&cea->gdt, get_cpu_gdt_rw(cpu), 1, gdt_prot);
 
        cea_map_percpu_pages(&cea->entry_stack_page,
                             per_cpu_ptr(&entry_stack_storage, cpu), 1,

The other bare use of cea_set_pte() in percpu_setup_debug_store() also appears
suspect.  The base debug_store area is mapped, but the buffers are not.

      reply	other threads:[~2022-11-04 19:39 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
2022-11-04 18:45             ` Dmitry Vyukov
2022-11-04 19:38               ` Sean Christopherson [this message]

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=Y2VqSBWY/xGM/HBF@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.