From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757053AbcGZWpU (ORCPT ); Tue, 26 Jul 2016 18:45:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50112 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753583AbcGZWpR convert rfc822-to-8bit (ORCPT ); Tue, 26 Jul 2016 18:45:17 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20160722214155.GA13726@kroah.com> References: <20160722214155.GA13726@kroah.com> To: Greg KH , Kirill Marinushkin Cc: dhowells@redhat.com, James Morris , "Serge E. Hallyn" , 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] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4896.1469573113.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Tue, 26 Jul 2016 23:45:13 +0100 Message-ID: <4897.1469573113@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 26 Jul 2016 22:45:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg KH 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" > Cc: "cve-assign@mitre.org" , Marco Grassi > 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:[] [] 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] [] ? big_key_crypt+0x2a0/0x2a0 > [94011.634034] [] key_create_or_update+0x361/0xa00 > [94011.634389] [] ? key_type_lookup+0xe0/0xe0 > [94011.634719] [] ? ___slab_alloc+0x179/0x4c0 > [94011.635050] [] ? __kmalloc+0x103/0x250 > [94011.635360] [] SyS_add_key+0x1f4/0x390 > [94011.635671] [] ? key_get_type_from_user.constprop.8+0xe0/0xe0 > [94011.636106] [] ? compat_start_thread+0x90/0x90 > [94011.636457] [] 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 [] big_key_preparse+0x1a4/0x540 > [94011.638775] RSP > [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 > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #include > > #include > #include > #include > #include > #include > #include > #include > > #include > > 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 > > #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