[syzbot] BUG: unable to handle kernel paging request in get_desc

[syzbot]

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+ffb4f0...@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
Code: de 02 00 00 83 e0 07 38 c2 0f 9e c1 84 d2 0f 95 c0 84 c1 0f 85 c9 02 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 d8 48 c1 e8 03 <0f> b6 0c 10 48 8d 43 07 48 89 c6 48 c1 ee 03 0f b6 14 16 48 89 de
RSP: 0018:ffffc9000431fd08 EFLAGS: 00010a06
RAX: 1fffffc5a1c22e00 RBX: fffffe2d0e117000 RCX: 0000000000000001
RDX: dffffc0000000000 RSI: 0000000000000001 RDI: 0000000000000006
RBP: ffffc9000431fdc0 R08: 0000000000000006 R09: 000000000000007f
R10: 0000000000000000 R11: 0000000000000001 R12: 1ffff92000863fa1
R13: dffffc0000000000 R14: 0000000000000000 R15: 000000000000007f
FS: 00007f250ff0e700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbc5a1c22e00 CR3: 0000000028c1f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
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
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 <00> 00 00 00 48 00 e0 0e 25 7f 00 00 ff ff ff ff ff ff ff ff 01 00
RSP: 0003:00007f250f3abf80 EFLAGS: 00010e96
RAX: 000000003ac744f0 RBX: 0000000000000000 RCX: 00007f250f3abf88
RDX: 0000000000000038 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f250f3abf80
R10: 0000000000000000 R11: ffffffff00000b5e R12: 00007f250f3abfb0
R13: 00007f250f360680 R14: 0000000000000038 R15: 000000003acf0fd6
</TASK>
Modules linked in:
CR2: fffffbc5a1c22e00
---[ end trace 0000000000000000 ]---
RIP: 0010:get_desc+0x128/0x460 arch/x86/lib/insn-eval.c:660
Code: de 02 00 00 83 e0 07 38 c2 0f 9e c1 84 d2 0f 95 c0 84 c1 0f 85 c9 02 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 d8 48 c1 e8 03 <0f> b6 0c 10 48 8d 43 07 48 89 c6 48 c1 ee 03 0f b6 14 16 48 89 de
RSP: 0018:ffffc9000431fd08 EFLAGS: 00010a06
RAX: 1fffffc5a1c22e00 RBX: fffffe2d0e117000 RCX: 0000000000000001
RDX: dffffc0000000000 RSI: 0000000000000001 RDI: 0000000000000006
RBP: ffffc9000431fdc0 R08: 0000000000000006 R09: 000000000000007f
R10: 0000000000000000 R11: 0000000000000001 R12: 1ffff92000863fa1
R13: dffffc0000000000 R14: 0000000000000000 R15: 000000000000007f
FS: 00007f250ff0e700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbc5a1c22e00 CR3: 0000000028c1f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: de 02 fiadds (%rdx)
2: 00 00 add %al,(%rax)
4: 83 e0 07 and $0x7,%eax
7: 38 c2 cmp %al,%dl
9: 0f 9e c1 setle %cl
c: 84 d2 test %dl,%dl
e: 0f 95 c0 setne %al
11: 84 c1 test %al,%cl
13: 0f 85 c9 02 00 00 jne 0x2e2
19: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
20: fc ff df
23: 48 89 d8 mov %rbx,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 0f b6 0c 10 movzbl (%rax,%rdx,1),%ecx <-- trapping instruction
2e: 48 8d 43 07 lea 0x7(%rbx),%rax
32: 48 89 c6 mov %rax,%rsi
35: 48 c1 ee 03 shr $0x3,%rsi
39: 0f b6 14 16 movzbl (%rsi,%rdx,1),%edx
3d: 48 89 de mov %rbx,%rsi


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Sean Christopherson]

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+ffb4f0...@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.

[Dmitry Vyukov]

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?

[Sean Christopherson]

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.

[Sean Christopherson]

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.

[Dmitry Vyukov]

On Fri, 4 Nov 2022 at 10:39, 'Sean Christopherson' via syzkaller-bugs

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?

[Sean Christopherson]

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.

[Dmitry Vyukov]

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 (?).

[Sean Christopherson]

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.