Message-ID: <CAKv+Gu9Y0TLOuMba43HPihYqy-kk0nttBfPj1_UukiYy1cBcFw@mail.gmail.com>
Date:   Tue, 21 Aug 2018 14:43:56 +0200
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Megha Dey <megha.dey@...ux.intel.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        "David S. Miller" <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        syzbot <syzbot+d5455bac3ba1ee9114e5@...kaller.appspotmail.com>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: KASAN: use-after-free Read in sha512_ctx_mgr_resubmit

On 20 August 2018 at 09:31, Eric Biggers <ebiggers@...nel.org> wrote:
> [+sha512-mb maintainers...]
>
> On Wed, Aug 15, 2018 at 09:00:04AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    7796916146b8 Merge branch 'x86-cpu-for-linus' of git://git..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=164b1922400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=265bef9882cce8d7
>> dashboard link: https://syzkaller.appspot.com/bug?extid=d5455bac3ba1ee9114e5
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1013478c400000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1349c8aa400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d5455bac3ba1ee9114e5@...kaller.appspotmail.com
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in sha512_ctx_mgr_resubmit.part.3+0x3b1/0x4a0
>> arch/x86/crypto/sha512-mb/sha512_mb.c:136
>> Read of size 4 at addr ffff8801b0b9e838 by task kworker/0:1/13
>>
>> CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 4.18.0+ #187
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Workqueue: crypto mcryptd_flusher
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
>>  print_address_description+0x6c/0x20b mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
>>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
>>  sha512_ctx_mgr_resubmit.part.3+0x3b1/0x4a0
>> arch/x86/crypto/sha512-mb/sha512_mb.c:136
>>  sha512_ctx_mgr_resubmit arch/x86/crypto/sha512-mb/sha512_mb.c:135 [inline]
>>  sha512_ctx_mgr_flush+0x5c/0xb0 arch/x86/crypto/sha512-mb/sha512_mb.c:367
>>  sha512_mb_flusher+0x27b/0x610 arch/x86/crypto/sha512-mb/sha512_mb.c:939
>>  mcryptd_flusher+0x342/0x4b0 crypto/mcryptd.c:208
>>  process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
>>  worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
>>  kthread+0x35a/0x420 kernel/kthread.c:246
>>  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
>>
>> Allocated by task 23902:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
>>  set_track mm/kasan/kasan.c:460 [inline]
>>  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
>>  __do_kmalloc mm/slab.c:3718 [inline]
>>  __kmalloc+0x14e/0x760 mm/slab.c:3727
>>  kmalloc include/linux/slab.h:518 [inline]
>>  sock_kmalloc+0x156/0x1f0 net/core/sock.c:1996
>>  hash_accept_parent_nokey+0x58/0x2e0 crypto/algif_hash.c:438
>>  hash_accept_parent+0x5b/0x80 crypto/algif_hash.c:465
>>  af_alg_accept+0x127/0x7d0 crypto/af_alg.c:296
>>  alg_accept+0x46/0x60 crypto/af_alg.c:332
>>  __sys_accept4+0x3b2/0x8a0 net/socket.c:1600
>>  __do_sys_accept4 net/socket.c:1635 [inline]
>>  __se_sys_accept4 net/socket.c:1632 [inline]
>>  __x64_sys_accept4+0x97/0xf0 net/socket.c:1632
>>  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> Freed by task 23902:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
>>  set_track mm/kasan/kasan.c:460 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
>>  __cache_free mm/slab.c:3498 [inline]
>>  kfree+0xd9/0x260 mm/slab.c:3813
>>  __sock_kfree_s net/core/sock.c:2017 [inline]
>>  sock_kfree_s+0x29/0x60 net/core/sock.c:2023
>>  hash_sock_destruct+0x157/0x1c0 crypto/algif_hash.c:427
>>  __sk_destruct+0x107/0xa60 net/core/sock.c:1573
>>  sk_destruct+0x78/0x90 net/core/sock.c:1608
>>  __sk_free+0xcf/0x300 net/core/sock.c:1619
>>  sk_free+0x42/0x50 net/core/sock.c:1630
>>  sock_put include/net/sock.h:1667 [inline]
>>  af_alg_release+0x6e/0x90 crypto/af_alg.c:126
>>  __sock_release+0xd7/0x260 net/socket.c:600
>>  sock_close+0x19/0x20 net/socket.c:1151
>>  __fput+0x355/0x8b0 fs/file_table.c:209
>>  ____fput+0x15/0x20 fs/file_table.c:243
>>  task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
>>  tracehook_notify_resume include/linux/tracehook.h:192 [inline]
>>  exit_to_usermode_loop+0x313/0x370 arch/x86/entry/common.c:166
>>  prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
>>  syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
>>  do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
>>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> The buggy address belongs to the object at ffff8801b0b9e340
>>  which belongs to the cache kmalloc-2048 of size 2048
>> The buggy address is located 1272 bytes inside of
>>  2048-byte region [ffff8801b0b9e340, ffff8801b0b9eb40)
>> The buggy address belongs to the page:
>> page:ffffea0006c2e780 count:1 mapcount:0 mapping:ffff8801dac00c40 index:0x0
>> compound_mapcount: 0
>> flags: 0x2fffc0000008100(slab|head)
>> raw: 02fffc0000008100 ffffea0007543a88 ffffea000760b188 ffff8801dac00c40
>> raw: 0000000000000000 ffff8801b0b9e340 0000000100000003 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>>  ffff8801b0b9e700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>  ffff8801b0b9e780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> > ffff8801b0b9e800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>                                         ^
>>  ffff8801b0b9e880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>  ffff8801b0b9e900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
>
> Apparently, the SHA multibuffer algorithms sometimes return success while the
> hash request is still being asynchronously processed, which allows an in-use
> request to be freed or reused.  It also allows the wrong digest value to be
> computed.

[...]

>
> Personally, I'm wondering why the SHA multibuffer code is in the kernel at all
> given all the severe issues it has that its authors/maintainers don't seem to be
> working very hard to fix.  The code is very difficult to understand due to the
> weird 3-layer design with "mcryptd" and other issues, making debugging it very
> time consuming; most of the code is duplicated in 3 places (sha1-mb, sha256-mb,
> and sha512-mb), making maintenance even more difficult; and most importantly
> there are severe bugs, including edge cases where it computes the wrong hash, as
> shown not only by this bug but also the sha256_mb bug I recently ran into.  It
> seems the algorithms were never tested under load to cover these edge cases.
>
> That's *not* acceptable for crypto code.  Security and correctness come first.
>
> Also as I've shown previously, in most cases the multibuffer SHA algorithms are
> ~1000x slower than the regular ones due to the flush delay.  So the performance
> argument for them actually seems pretty tenuous...  And, isn't AVX2 multibuffer
> useless on new processors, which have SHA instructions?
>
> I'd also be very interested to hear an explanation for why systemwide sharing of
> hash jobs doesn't enable side-channel attacks and isn't just the latest example
> of prioritizing "performance" over security?
>
> We need to have higher standards for crypto and not accept buggy spaghetti code
> just because it's slightly faster in some artificial microbenchmark.
>
> So unless major improvements are made, I personally think we'd be much better
> off without the SHA multibuffer algorithms in the kernel.
>

I agree. The code is obviously broken in a way that would have been
noticed if it were in wide use, and it is too complicated for mere
mortals to fix or maintain. I suggest we simply remove it for now, and
if anyone wants to reintroduce it, we can review the code *and* the
justification for the approach from scratch (in which case we should
consider factoring out the algo agnostics plumbing in a way that
allows it to be reused by other architectures as well)

Powered by blists - more mailing lists