From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 647876B0253 for ; Sat, 9 Jul 2016 03:55:47 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id r190so25695216wmr.0 for ; Sat, 09 Jul 2016 00:55:47 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com. [2a00:1450:400c:c09::242]) by mx.google.com with ESMTPS id a84si1190160wmd.66.2016.07.09.00.55.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 00:55:45 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id k123so10603953wme.2 for ; Sat, 09 Jul 2016 00:55:45 -0700 (PDT) Date: Sat, 9 Jul 2016 09:55:40 +0200 From: Ingo Molnar Subject: Re: [PATCH 0/9] mm: Hardened usercopy Message-ID: <20160709075539.GA27852@gmail.com> References: <1467843928-29351-1-git-send-email-keescook@chromium.org> <1468032243.13253.59.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1468032243.13253.59.camel@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Laura Abbott , Kees Cook , linux-kernel@vger.kernel.org, Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , x86@kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com * Rik van Riel wrote: > On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote: > > > > Even with the SLUB fixup I'm still seeing this blow up on my arm64 > > system. This is a > > Fedora rawhide kernel + the patches > > > > [ 0.666700] usercopy: kernel memory exposure attempt detected from > > fffffc0008b4dd58 () (8 bytes) > > [ 0.666720] CPU: 2 PID: 79 Comm: modprobe Tainted: > > G W 4.7.0-0.rc6.git1.1.hardenedusercopy.fc25.aarch64 #1 > > [ 0.666733] Hardware name: AppliedMicro Mustang/Mustang, BIOS > > 1.1.0 Nov 24 2015 > > [ 0.666744] Call trace: > > [ 0.666756] [] dump_backtrace+0x0/0x1e8 > > [ 0.666765] [] show_stack+0x24/0x30 > > [ 0.666775] [] dump_stack+0xa4/0xe0 > > [ 0.666785] [] __check_object_size+0x6c/0x230 > > [ 0.666795] [] create_elf_tables+0x74/0x420 > > [ 0.666805] [] load_elf_binary+0x828/0xb70 > > [ 0.666814] [] search_binary_handler+0xb4/0x240 > > [ 0.666823] [] do_execveat_common+0x63c/0x950 > > [ 0.666832] [] do_execve+0x3c/0x50 > > [ 0.666841] [] > > call_usermodehelper_exec_async+0xe8/0x148 > > [ 0.666850] [] ret_from_fork+0x10/0x50 > > > > This happens on every call to execve. This seems to be the first > > copy_to_user in > > create_elf_tables. I didn't get a chance to debug and I'm going out > > of town > > all of next week so all I have is the report unfortunately. config > > attached. > > That's odd, this should be copying a piece of kernel data (not text) > to userspace. > > from fs/binfmt_elf.c > > const char *k_platform = ELF_PLATFORM; > > ... > size_t len = strlen(k_platform) + 1; > > u_platform = (elf_addr_t __user *)STACK_ALLOC(p, len); > if (__copy_to_user(u_platform, k_platform, len)) > return -EFAULT; > > from arch/arm/include/asm/elf.h: > > #define ELF_PLATFORM_SIZE 8 > #define ELF_PLATFORM (elf_platform) > > extern char elf_platform[]; > > from arch/arm/kernel/setup.c: > > char elf_platform[ELF_PLATFORM_SIZE]; > EXPORT_SYMBOL(elf_platform); > > ... > > snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c", > list->elf_name, ENDIANNESS); > > How does that end up in the .text section of the > image, instead of in one of the various data sections? > > What kind of linker oddity is going on with ARM? I think the crash happened on ARM64, not ARM. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org