Re: general protection fault in _initial_num_blocks_is_ADDR

From: Eric Biggers <ebiggers@kernel.org>
To: syzbot <syzbot+b9cab61577c8d0a3c48e@syzkaller.appspotmail.com>
Cc: linux-crypto@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: general protection fault in _initial_num_blocks_is_ADDR
Date: Sat, 7 Mar 2020 13:47:48 -0800	[thread overview]
Message-ID: <20200307214748.GQ15444@sol.localdomain> (raw)
In-Reply-To: <0000000000000147a30599cd7d93@google.com>

On Sun, Dec 15, 2019 at 11:52:08PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    07c4b9e9 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1049e3dee00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d
> dashboard link: https://syzkaller.appspot.com/bug?extid=b9cab61577c8d0a3c48e
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b9cab61577c8d0a3c48e@syzkaller.appspotmail.com
> 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 26867 Comm: kworker/u4:3 Not tainted 5.5.0-rc1-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: pencrypt_parallel padata_parallel_worker
> RIP: 0010:_initial_num_blocks_is_017529+0x2f7/0x3e1
> Code: 00 00 c4 e2 71 dd c8 c4 e2 69 dd d0 c4 e2 61 dd d8 c4 e2 59 dd e0 c4
> e2 51 dd e8 c4 e2 49 dd f0 c4 e2 41 dd f8 c4 62 39 dd c0 <c4> 21 7a 6f 24 19
> c4 c1 71 ef cc c4 a1 7a 7f 0c 1a c4 21 7a 6f 64
> RSP: 0018:ffffc90004ed7680 EFLAGS: 00010206
> RAX: 0000000000000010 RBX: 0000000000000f80 RCX: 0005088000000080
> RDX: ffff888066da800d RSI: ffffc90004ed78f0 RDI: ffff888062285850
> RBP: ffffc90004ed7b20 R08: 0000000000000f80 R09: 000000000000000d
> R10: 0000000000000080 R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000f80 R14: ffffc90004ed7728 R15: 0000000000004000
> FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b2d333000 CR3: 0000000094a09000 CR4: 00000000001426f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  gcmaes_encrypt arch/x86/crypto/aesni-intel_glue.c:840 [inline]
>  generic_gcmaes_encrypt+0x10d/0x160 arch/x86/crypto/aesni-intel_glue.c:1019
>  crypto_aead_encrypt+0xaf/0xf0 crypto/aead.c:94
>  simd_aead_encrypt+0x1a6/0x2b0 crypto/simd.c:335
>  crypto_aead_encrypt+0xaf/0xf0 crypto/aead.c:94
>  pcrypt_aead_enc+0x19/0x80 crypto/pcrypt.c:76
>  padata_parallel_worker+0x28f/0x470 kernel/padata.c:81
>  process_one_work+0x9af/0x1740 kernel/workqueue.c:2264
>  worker_thread+0x98/0xe40 kernel/workqueue.c:2410
>  kthread+0x361/0x430 kernel/kthread.c:255
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> Modules linked in:

This only happened once, there's still no reproducer, and there have been
potentially related fixes to crypto/pcrypt.c since then.  So I'm invalidating
this bug report.

#syz invalid