kernel-hardening - Re: [PATCH 0/9] mm: Hardened usercopy

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Jul 2016 09:55:40 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Rik van Riel <riel@...hat.com>
Cc: Laura Abbott <labbott@...hat.com>, Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org,
	Casey Schaufler <casey@...aufler-ca.com>,
	PaX Team <pageexec@...email.hu>,
	Brad Spengler <spender@...ecurity.net>,
	Russell King <linux@...linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>,
	"David S. Miller" <davem@...emloft.net>, x86@...nel.org,
	Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...e.de>,
	Mathias Krause <minipli@...glemail.com>, Jan Kara <jack@...e.cz>,
	Vitaly Wool <vitalywool@...il.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Laura Abbott <labbott@...oraproject.org>,
	linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-mm@...ck.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 0/9] mm: Hardened usercopy


* Rik van Riel <riel@...hat.com> 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 (<kernel text>) (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] [<fffffc0008088a20>] dump_backtrace+0x0/0x1e8
> > [    0.666765] [<fffffc0008088c2c>] show_stack+0x24/0x30
> > [    0.666775] [<fffffc0008455344>] dump_stack+0xa4/0xe0
> > [    0.666785] [<fffffc000828d874>] __check_object_size+0x6c/0x230
> > [    0.666795] [<fffffc00083a5748>] create_elf_tables+0x74/0x420
> > [    0.666805] [<fffffc00082fb1f0>] load_elf_binary+0x828/0xb70
> > [    0.666814] [<fffffc0008298b4c>] search_binary_handler+0xb4/0x240
> > [    0.666823] [<fffffc0008299864>] do_execveat_common+0x63c/0x950
> > [    0.666832] [<fffffc0008299bb4>] do_execve+0x3c/0x50
> > [    0.666841] [<fffffc00080e3720>]
> > call_usermodehelper_exec_async+0xe8/0x148
> > [    0.666850] [<fffffc0008084a80>] 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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.