KASAN: slab-out-of-bounds Write in sha3_update (2)

[syzbot]

Hello,

syzkaller hit the following crash on
9035a8961b504d0997369509ab8c6b1f0a4ee33d
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.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


audit: type=1400 audit(1513919078.260:7): avc: denied { map } for
pid=3152 comm="syzkaller717822" path="/root/syzkaller717822551" dev="sda1"
ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
==================================================================
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
BUG: KASAN: slab-out-of-bounds in sha3_update+0xdf/0x2e0
crypto/sha3_generic.c:161
Write of size 192 at addr ffff8801cf0e3b3c by task syzkaller717822/3152

CPU: 0 PID: 3152 Comm: syzkaller717822 Not tainted 4.15.0-rc4+ #232
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:344 [inline]
sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
crypto_shash_update+0xda/0x240 crypto/shash.c:110
hmac_update+0x7e/0xa0 crypto/hmac.c:122
crypto_shash_update+0xda/0x240 crypto/shash.c:110
kdf_ctr security/keys/dh.c:181 [inline]
keyctl_dh_compute_kdf security/keys/dh.c:226 [inline]
__keyctl_dh_compute+0x160f/0x1990 security/keys/dh.c:398
keyctl_dh_compute+0xac/0xf3 security/keys/dh.c:434
SYSC_keyctl security/keys/keyctl.c:1741 [inline]
SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1637
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x43feb9
RSP: 002b:00007ffd3aef51a8 EFLAGS: 00000217 ORIG_RAX: 00000000000000fa
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043feb9
RDX: 0000000020c2cfff RSI: 00000000204c8ff4 RDI: 0000000000000017
RBP: 00000000006ca018 R08: 00000000208e6fd4 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000217 R12: 0000000000401820
R13: 00000000004018b0 R14: 0000000000000000 R15: 0000000000000000

Allocated by task 3152:
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
__do_kmalloc mm/slab.c:3708 [inline]
__kmalloc+0x162/0x760 mm/slab.c:3717
kmalloc include/linux/slab.h:504 [inline]
kdf_alloc security/keys/dh.c:111 [inline]
__keyctl_dh_compute+0x2b0/0x1990 security/keys/dh.c:288
keyctl_dh_compute+0xac/0xf3 security/keys/dh.c:434
SYSC_keyctl security/keys/keyctl.c:1741 [inline]
SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1637
entry_SYSCALL_64_fastpath+0x1f/0x96

Freed by task 1637:
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
__cache_free mm/slab.c:3488 [inline]
kfree+0xd6/0x260 mm/slab.c:3803
kernfs_fop_release+0x13f/0x180 fs/kernfs/file.c:783
__fput+0x327/0x7e0 fs/file_table.c:210
____fput+0x15/0x20 fs/file_table.c:244
task_work_run+0x199/0x270 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:191 [inline]
exit_to_usermode_loop+0x296/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
entry_SYSCALL_64_fastpath+0x94/0x96

The buggy address belongs to the object at ffff8801cf0e3a40
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 252 bytes inside of
512-byte region [ffff8801cf0e3a40, ffff8801cf0e3c40)
The buggy address belongs to the page:
page:000000001ae65fa7 count:1 mapcount:0 mapping:0000000077bf18b4
index:0xffff8801cf0e3cc0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801cf0e3040 ffff8801cf0e3cc0 0000000100000005
raw: ffff8801db001738 ffffea00073c1c20 ffff8801db000940 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8801cf0e3a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801cf0e3b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801cf0e3b80: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
^
ffff8801cf0e3c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801cf0e3c80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
==================================================================


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzk...@googlegroups.com>

syzbot will keep track of this bug report.
Once a fix for this bug is merged into any tree, reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Eric Biggers]

[+Cc keyr...@vger.kernel.org]

The problem is that KEYCTL_DH_COMPUTE allows the user to request and use any
hash algorithm as an unkeyed hash without checking whether it is in fact
unkeyed.

We could fix this by checking for !crypto_shash_alg_has_setkey() after
allocating the hash, but now I'd really like to solve this for all users by
having crypto_[as]hash_init() and crypto_[as]hash_digest() automatically return
-ENOKEY if a key is needed and one hasn't been set. That would also have solved
the bug I fixed specifically for HMAC by "crypto: hmac - require that the
underlying hash algorithm is unkeyed".

Eric

[Eric Biggers]

Fixed in cryptodev/master by:

#syz fix: crypto: hash - prevent using keyed hashes without setting key