From: Stephan Mueller Subject: Re: GPF in lrw_crypt Date: Mon, 21 Dec 2015 23:58:28 +0100 Message-ID: <2161679.syjMOsUrgF@myon.chronox.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Herbert Xu , "David S. Miller" , linux-crypto@vger.kernel.org, LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin , Kees Cook To: Dmitry Vyukov Return-path: Received: from mail.eperm.de ([89.247.134.16]:40792 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751642AbbLUW6a (ORCPT ); Mon, 21 Dec 2015 17:58:30 -0500 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: Am Donnerstag, 17. Dezember 2015, 13:59:11 schrieb Dmitry Vyukov: Hi Dmitry, > Hello, > > The following program causes GPF in lrw_crypt: Here we are: this problem looks very much like the error reprt about a GFP in gf128mul_64_bbe. > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include > #include > #include > > int main() > { > long r0 = syscall(SYS_socket, 0x26ul, 0x5ul, 0x0ul, 0, 0, 0); > long r1 = syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x2ul, > 0x32ul, 0xfffffffffffffffful, 0x0ul); > *(uint16_t*)0x20001000 = 0x26; > memcpy((void*)0x20001002, > "\x73\x6b\x63\x69\x70\x68\x65\x72\x00\x00\x00\x00\x00\x00", 14); > *(uint32_t*)0x20001010 = 0xf; > *(uint32_t*)0x20001014 = 0x100; > memcpy((void*)0x20001018, > "\x6c\x72\x77\x28\x74\x77\x6f\x66\x69\x73\x68\x29\x00\x00\x00\x00\x00\x00\x0 > 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 > 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 > 0\x00\x00\x00\x00\x00\x00\x00", 64); > long r7 = syscall(SYS_bind, r0, 0x20001000ul, 0x58ul, 0, 0, 0); > long r8 = syscall(SYS_accept4, r0, 0x0ul, 0x200023fdul, 0x800ul, 0, > 0); memcpy((void*)0x20002fd8, > "\x09\xf1\x98\x36\x3f\x7d\x29\x96\x55\xe6\xa2\x42\x45\x67\x8f\x7c\x27\x44\x5 > 1\x6f\xbe\x4d\x52\x6f\x40\xaf\xe0\xd6\x04\x8d\x86\x36\x08\xc8\x55\xb8\xfe\x6 > e\x89\xef\x15\x2d\x07\x9a\x74\xab\xc7\x47\x26\xb5\x00\x93\x3b\x59\xe2\x1f\x6 > a\x29\x76\x7f\x9d\x3a\x86\x38\xda\x3e\xfb\xbe\x63\x2e\x38\x2f\x5c\x1c\x4d\xb > 8\x53\xf9\x97\xdb\x4a\xcc\xad\x55\xb3\xb5\xa0\xb4\xad\xfb\x39\xe5\x44\x12\x0 > b\x5f\x03\xbf\xc7\x28\x36\x1a\x7b\x4a\xff\x3e\x71\x17\x44\xf3\x09\xfb\x44\x4 > 1\x55\x1b\x6e\x6c\xcd\x03\x39\x66\xe2\x87\x65\xdd\x66\x7c\x00\x9f\x46\x54\x6 > 6\xf1\xa8\x4b\xd9\x10\xdc\x45\xd0\x57\x5c\x5e\x97\x42\x3a\xc9\x26\x5a\x55\x5 > 7\x65\x5f\x38\x54\xdd\x1e\xd8\x89\xe0\x34\xf0\x9e\x65\xf8\x89\x8e\xe4\x02\xd > c\xa2\xa8\x45\x9c\xe9\xca\xef\xad\xdc\x74\xb5", 182); > long r10 = syscall(SYS_write, r8, 0x20002fd8ul, 0xb6ul, 0, 0, 0); > *(uint64_t*)0x20000fb8 = 0x20004fff; > *(uint64_t*)0x20000fc0 = 0x94; > *(uint64_t*)0x20000fc8 = 0x20000000; > *(uint64_t*)0x20000fd0 = 0x5d; > *(uint64_t*)0x20000fd8 = 0x20000f1b; > *(uint64_t*)0x20000fe0 = 0xe5; > *(uint64_t*)0x20000fe8 = 0x20004b08; > *(uint64_t*)0x20000ff0 = 0xe9; > *(uint64_t*)0x20000ff8 = 0x20002000; > *(uint64_t*)0x20001000 = 0x1000; > long r21 = syscall(SYS_readv, r8, 0x20000fb8ul, 0x5ul, 0, 0, 0); > return 0; > } > > > ============================================================================ > ==== kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory > accessgeneral protection fault: 0000 [#1] SMP KASAN > Modules linked in: > CPU: 2 PID: 6912 Comm: a.out Not tainted 4.4.0-rc3+ #151 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: ffff88005ee61680 ti: ffff88005fef0000 task.ti: ffff88005fef0000 RIP: > 0010:[] [] gf128mul_64k_bbe+0x89/0x3f0 > RSP: 0018:ffff88005fef7590 EFLAGS: 00010246 > RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000000 > RDX: ffffed000bfdee9f RSI: ffff88005ee61e40 RDI: ffffed000bfdeeab > RBP: ffff88005fef7650 R08: 0000000000000001 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: ffff88005fef7870 > R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff1000bfdeeb8 > FS: 00000000026a3880(0063) GS:ffff88006ce00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000020000fb8 CR3: 000000005ffa0000 CR4: 00000000000006e0 > Stack: > ffff88005fef7730 ffff880000000fff 1ffff1000bfdeeb8 ffff88005fef7870 > ffff88005fef7710 0000000000000000 0000000041b58ab3 ffffffff87ab3a79 > ffffffff82bf9580 ffffffff82bafa9b ffff88005ee61680 0000000000000001 > Call Trace: > [] lrw_crypt+0x29d/0xd20 crypto/lrw.c:248 > [] lrw_decrypt+0xf2/0x150 > arch/x86/crypto/serpent_avx2_glue.c:270 > [] async_decrypt+0x1c1/0x2c0 crypto/blkcipher.c:443 > [< inline >] crypto_ablkcipher_decrypt include/linux/crypto.h:921 > [< inline >] skcipher_recvmsg_sync crypto/algif_skcipher.c:676 > [] skcipher_recvmsg+0x1029/0x1f10 > crypto/algif_skcipher.c:706 [< inline >] sock_recvmsg_nosec > net/socket.c:712 > [] sock_recvmsg+0xaa/0xe0 net/socket.c:720 > [] sock_read_iter+0x273/0x3d0 net/socket.c:797 > [] do_iter_readv_writev+0x14e/0x2c0 fs/read_write.c:664 > [] do_readv_writev+0x2e2/0x880 fs/read_write.c:808 > [] vfs_readv+0x95/0xd0 fs/read_write.c:834 > [< inline >] SYSC_readv fs/read_write.c:860 > [] SyS_readv+0x111/0x2f0 fs/read_write.c:852 > [] entry_SYSCALL_64_fastpath+0x16/0x7a > arch/x86/entry/entry_64.S:185 > Code: 04 00 00 f4 f4 c7 40 08 f3 f3 f3 f3 e8 d1 e9 a0 fe 4d 85 f6 0f > 84 f6 01 00 00 4c 89 f1 48 b8 00 00 00 00 00 fc ff df 48 c1 e9 03 <80> > 3c 01 00 0f 85 48 03 00 00 48 8b 5c 24 18 4d 8b 26 48 83 c3 > RIP [] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379 > RSP > ---[ end trace 018c54843b88ec1d ]--- > > > On upstream commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8 (Nov 29). > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ciao Stephan