From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Sender: Ingo Molnar Date: Sat, 9 Jul 2016 09:55:40 +0200 From: Ingo Molnar 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> Subject: [kernel-hardening] Re: [PATCH 0/9] mm: Hardened usercopy 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 List-ID: * 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 0/9] mm: Hardened usercopy Date: Sat, 9 Jul 2016 09:55:40 +0200 Message-ID: <20160709075539.GA27852@gmail.com> References: <1467843928-29351-1-git-send-email-keescook@chromium.org> <1468032243.13253.59.camel@redhat.com> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Sender: Ingo Molnar Content-Disposition: inline In-Reply-To: <1468032243.13253.59.camel@redhat.com> 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 List-Id: linux-arch.vger.kernel.org * 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com ([74.125.82.65]:35306 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756527AbcGIHz6 (ORCPT ); Sat, 9 Jul 2016 03:55:58 -0400 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: linux-arch-owner@vger.kernel.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 Message-ID: <20160709075540.nvEGZ8DMXuAbg9G1VMAgMRO5yQkkMf4bDUqW45g2Vf0@z> * 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Date: Sat, 09 Jul 2016 07:55:40 +0000 Subject: Re: [PATCH 0/9] mm: Hardened usercopy Message-Id: <20160709075539.GA27852@gmail.com> List-Id: References: <1467843928-29351-1-git-send-email-keescook@chromium.org> <1468032243.13253.59.camel@redhat.com> In-Reply-To: <1468032243.13253.59.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: > >=A0 > > Even with the SLUB fixup I'm still seeing this blow up on my arm64 > > system. This is a > > Fedora rawhide kernel + the patches > >=20 > > [=A0=A0=A0=A00.666700] usercopy: kernel memory exposure attempt detecte= d from > > fffffc0008b4dd58 () (8 bytes) > > [=A0=A0=A0=A00.666720] CPU: 2 PID: 79 Comm: modprobe Tainted: > > G=A0=A0=A0=A0=A0=A0=A0=A0W=A0=A0=A0=A0=A0=A0=A04.7.0-0.rc6.git1.1.harde= nedusercopy.fc25.aarch64 #1 > > [=A0=A0=A0=A00.666733] Hardware name: AppliedMicro Mustang/Mustang, BIOS > > 1.1.0 Nov 24 2015 > > [=A0=A0=A0=A00.666744] Call trace: > > [=A0=A0=A0=A00.666756] [] dump_backtrace+0x0/0x1e8 > > [=A0=A0=A0=A00.666765] [] show_stack+0x24/0x30 > > [=A0=A0=A0=A00.666775] [] dump_stack+0xa4/0xe0 > > [=A0=A0=A0=A00.666785] [] __check_object_size+0x6c/0x= 230 > > [=A0=A0=A0=A00.666795] [] create_elf_tables+0x74/0x420 > > [=A0=A0=A0=A00.666805] [] load_elf_binary+0x828/0xb70 > > [=A0=A0=A0=A00.666814] [] search_binary_handler+0xb4/= 0x240 > > [=A0=A0=A0=A00.666823] [] do_execveat_common+0x63c/0x= 950 > > [=A0=A0=A0=A00.666832] [] do_execve+0x3c/0x50 > > [=A0=A0=A0=A00.666841] [] > > call_usermodehelper_exec_async+0xe8/0x148 > > [=A0=A0=A0=A00.666850] [] ret_from_fork+0x10/0x50 > >=20 > > 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. >=20 > That's odd, this should be copying a piece of kernel data (not text) > to userspace. >=20 > from fs/binfmt_elf.c >=20 > =A0 =A0 =A0 =A0 const char *k_platform =3D ELF_PLATFORM; >=20 > ... > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 size_t len =3D strlen(k_platform) + 1; > =09 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 u_platform =3D (elf_addr_t __user *)STACK= _ALLOC(p, len); > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (__copy_to_user(u_plat= form, k_platform, len)) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0r= eturn -EFAULT; >=20 > from arch/arm/include/asm/elf.h: >=20 > #define ELF_PLATFORM_SIZE 8 > #define ELF_PLATFORM=A0=A0=A0=A0(elf_platform) >=20 > extern char elf_platform[]; >=20 > from arch/arm/kernel/setup.c: >=20 > char elf_platform[ELF_PLATFORM_SIZE]; > EXPORT_SYMBOL(elf_platform); >=20 > ... >=20 > =A0=A0=A0=A0=A0=A0=A0=A0snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c", > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0list->elf_name, ENDIAN= NESS); >=20 > How does that end up in the .text section of the > image, instead of in one of the various data sections? >=20 > What kind of linker oddity is going on with ARM? I think the crash happened on ARM64, not ARM. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: mingo@kernel.org (Ingo Molnar) Date: Sat, 9 Jul 2016 09:55:40 +0200 Subject: [PATCH 0/9] mm: Hardened usercopy In-Reply-To: <1468032243.13253.59.camel@redhat.com> References: <1467843928-29351-1-git-send-email-keescook@chromium.org> <1468032243.13253.59.camel@redhat.com> Message-ID: <20160709075539.GA27852@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * 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 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