Re: general protection fault in crypto_chacha20_crypt

2017-12-11 Thread Eric Biggers
On Wed, Nov 29, 2017 at 01:24:38AM -0800, Eric Biggers wrote:
> 
> The bug is that the skcipher_walk API doesn't set the IV for zero-length 
> inputs,
> while some algorithms (e.g. ChaCha20) access the IV even if the input is
> zero-length.  So it was dereferencing a pointer which came from uninitialized
> stack memory.  I've sent out a fix:
> 
> "crypto: skcipher - set walk.iv for zero-length inputs"
> 

#syz fix: crypto: skcipher - set walk.iv for zero-length inputs


Re: general protection fault in crypto_chacha20_crypt

2017-11-29 Thread Eric Biggers
On Tue, Nov 28, 2017 at 06:22:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 6285 Comm: syzkaller774851 Not tainted 4.14.0+ #128
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> task: 8801c63fa140 task.stack: 8801c52e8000
> RIP: 0010:__le32_to_cpup include/uapi/linux/byteorder/little_endian.h:58
> [inline]
> RIP: 0010:le32_to_cpuvp crypto/chacha20_generic.c:19 [inline]
> RIP: 0010:crypto_chacha20_init crypto/chacha20_generic.c:58 [inline]
> RIP: 0010:crypto_chacha20_crypt+0x537/0xbd0 crypto/chacha20_generic.c:91
> RSP: 0018:8801c52ef5b0 EFLAGS: 00010246
> RAX: dc00 RBX: ef9ecba1 RCX: 82265bab
> RDX:  RSI: 8801c5554780 RDI: 8801c52ef64c
> RBP: 8801c52ef7d0 R08: ed0038a8ee6c R09: 8801c5477340
> R10: 8801c52ef7f0 R11: ed0038a8ee6b R12: 
> R13:  R14: 5c3d10a6 R15: dc00
> FS:  7f7725fce700() GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20216000 CR3: 0001c5566000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  chacha20_simd+0xe4/0x410 arch/x86/crypto/chacha20_glue.c:78
>  crypto_skcipher_decrypt include/crypto/skcipher.h:463 [inline]
>  _skcipher_recvmsg crypto/algif_skcipher.c:133 [inline]
>  skcipher_recvmsg+0xb06/0xf30 crypto/algif_skcipher.c:164
>  skcipher_recvmsg_nokey+0x60/0x80 crypto/algif_skcipher.c:283
>  sock_recvmsg_nosec net/socket.c:805 [inline]
>  sock_recvmsg+0xc9/0x110 net/socket.c:812
>  ___sys_recvmsg+0x29b/0x630 net/socket.c:2207
>  __sys_recvmsg+0xe2/0x210 net/socket.c:2252
>  SYSC_recvmsg net/socket.c:2264 [inline]
>  SyS_recvmsg+0x2d/0x50 net/socket.c:2259
>  entry_SYSCALL_64_fastpath+0x1f/0x96

The bug is that the skcipher_walk API doesn't set the IV for zero-length inputs,
while some algorithms (e.g. ChaCha20) access the IV even if the input is
zero-length.  So it was dereferencing a pointer which came from uninitialized
stack memory.  I've sent out a fix:

"crypto: skcipher - set walk.iv for zero-length inputs"