linux-kernel - Re: BUG: unable to handle kernel paging request in __switch

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-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1712141807400.4998@nanos>
Date:   Thu, 14 Dec 2017 18:12:35 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     syzbot 
        <bot+1f445b1009b8eeededa30fe62ccf685f2ec9d155@...kaller.appspotmail.com>
cc:     bp@...e.de, dsafonov@...tuozzo.com, hpa@...or.com,
        linux-kernel@...r.kernel.org, luto@...nel.org, me@...ehuey.com,
        mingo@...hat.com, syzkaller-bugs@...glegroups.com, x86@...nel.org
Subject: Re: BUG: unable to handle kernel paging request in __switch_to

On Sun, 3 Dec 2017, syzbot wrote:
> BUG: unable to handle kernel paging request at fffffffffffffff8
> IP: switch_fpu_prepare arch/x86/include/asm/fpu/internal.h:535 [inline]
> IP: __switch_to+0x95b/0x1330 arch/x86/kernel/process_64.c:407
> PGD 5e28067 P4D 5e28067 PUD 5e2a067 PMD 0
> Oops: 0002 [#1] SMP KASAN
> Dumping ftrace buffer:
>   (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4355 Comm: syz-executor1 Not tainted 4.15.0-rc1-next-20171129+ #55
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
> 01/01/2011
> task: ffff8801cf1e80c0 task.stack: ffff8801d03a8000
> RIP: 0010:switch_fpu_prepare arch/x86/include/asm/fpu/internal.h:535 [inline]
> RIP: 0010:__switch_to+0x95b/0x1330 arch/x86/kernel/process_64.c:407
> RSP: 0018:ffff8801cb867468 EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff8801cc0b8500 RCX: ffff8801cc0b9a00
> RDX: 1ffff10039e3d2d0 RSI: 0000000000000000 RDI: ffff8801cf1e96c0
> RBP: ffff8801cb867628 R08: ffff8801db427918 R09: 1ffff1003a075dfe
> R10: ffff8801cf1e80c0 R11: 0000000000000003 R12: ffff8801cf1e80c0
> R13: ffff8801cf1e96c0 R14: ffff8801cf1e9680 R15: ffff8801cf1e95c0
> FS:  00007f16e6ea0700(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: fffffffffffffff8 CR3: 00000001cc778000 CR4: 00000000001426f0
> Call Trace:
> Code: b8 00 00 00 00 00 fc ff df 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f
> 8e d5 06 00 00 8b 85 70 fe ff ff 41 89 84 24 c0 15 00 00 <cc> 1f 44 00 00 65

  <cc> is an int3 !?!?!

> 8b 05 99 01 dc 7e 89 c0 48 0f a3 05 df 97 39

That's the second report I'm staring at today which has CR2
fffffffffffffffx and points to a faulting instruction which does not make
any sense at all.

Thanks,

	tglx