Am Donnerstag, 17. Dezember 2015, 14:00:23 schrieb Dmitry Vyukov: Hi Herbert, After digging a bit here, I find the following: - When using the test app on my system, I get a GPF in twofish, which means that the problem is not tied to a particular cipher implementation. - When analyzing gf128mul_64k_bbe, I see that the NULL pointer deference seems to be triggered *after* the last operation in that function. Can it be that there is some memory corruption in that function where the return pointer is somehow overwritten? > Hello, > > The following program causes GPF in gf128mul_64k_bbe: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include <syscall.h> > #include <string.h> > #include <stdint.h> > > int main() > { > long r0 = syscall(SYS_socket, 0x26ul, 0x5ul, 0x0ul, 0, 0, 0); > long r1 = syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, > 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\x63\x61\x6d\x65\x6c\x6c\x69\x61\x29\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); *(uint32_t*)0x20002000 = 0x12; > *(uint32_t*)0x20002004 = 0x8; > *(uint64_t*)0x20002008 = 0x0; > *(uint16_t*)0x20002010 = 0x4d; > long r13 = syscall(SYS_write, r8, 0x20002000ul, 0x12ul, 0, 0, 0); > memcpy((void*)0x20000a56, > "\x05\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\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\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\x00\x00\x00\x00\x00\x00\x00", 128); > long r15 = syscall(SYS_recvfrom, r8, 0x20000000ul, 0xb6ul, > 0x0ul, 0x20000a56ul, 0x80ul); > return 0; > } > > > general protection fault: 0000 [#2] SMP KASAN > Modules linked in: > CPU: 0 PID: 6955 Comm: executor Not tainted 4.4.0-rc3+ #151 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: ffff88005fc88000 ti: ffff880062478000 task.ti: ffff880062478000 RIP: > 0010:[<ffffffff82bf9609>] > [<ffffffff82bf9609>] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379 > RSP: 0018:ffff88006247f720 EFLAGS: 00010246 > RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000000 > RDX: ffffed000c48fed1 RSI: 0000000000000000 RDI: ffffed000c48fedd > RBP: ffff88006247f7e0 R08: ffff88003dfd1158 R09: 0000000000001000 > R10: 0000000000000010 R11: 1ffff100075eeb92 R12: ffff88006247fa00 > R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff1000c48feea > FS: 00007f21e795f700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000020000a56 CR3: 0000000060c4b000 CR4: 00000000000006f0 > Stack: > ffff88006247f8c0 ffff88006247f8b8 1ffff1000c48feea ffff88006247fa00 > ffff88006247f8a0 0000000000000000 0000000041b58ab3 ffffffff87ab3a79 > ffffffff82bf9580 ffffffff82bafa9b 0000000000000000 ffff88006247f7a0 > Call Trace: > [<ffffffff82c04b9d>] lrw_crypt+0x29d/0xd20 crypto/lrw.c:248 > [<ffffffff812b838b>] lrw_decrypt+0xeb/0x140 > arch/x86/crypto/serpent_avx2_glue.c:270 > [<ffffffff82babe81>] 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 > [<ffffffff82d2e7b9>] skcipher_recvmsg+0x1029/0x1f10 > crypto/algif_skcipher.c:706 [< inline >] sock_recvmsg_nosec > net/socket.c:712 > [<ffffffff856b1c8a>] sock_recvmsg+0xaa/0xe0 net/socket.c:720 > [<ffffffff856b2424>] SYSC_recvfrom+0x1e4/0x370 net/socket.c:1707 > [<ffffffff856b7570>] SyS_recvfrom+0x40/0x50 net/socket.c:1681 > [<ffffffff86a89fb6>] 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 [<ffffffff82bf9609>] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379 > RSP <ffff88006247f720> > ---[ end trace 722d56533c7c99a7 ]--- > > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
