Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933451AbdCaX6M (ORCPT ); Fri, 31 Mar 2017 19:58:12 -0400 Received: from mail-io0-f178.google.com ([209.85.223.178]:36382 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932756AbdCaX6K (ORCPT ); Fri, 31 Mar 2017 19:58:10 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170330194143.cbracica3w3ijrcx@codemonkey.org.uk> <20170331171724.nm22iqiellfsvj5z@codemonkey.org.uk> From: Kees Cook Date: Fri, 31 Mar 2017 16:58:09 -0700 X-Google-Sender-Auth: f7t2vBiUi3HwYAdlqZuN2ZNTBAg Message-ID: Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! To: Linus Torvalds Cc: Dave Jones , Tommi Rantala , Linux-MM , LKML , Laura Abbott , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Eric Biggers Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2749 Lines: 76 On Fri, Mar 31, 2017 at 11:26 AM, Linus Torvalds wrote: > On Fri, Mar 31, 2017 at 10:32 AM, Kees Cook wrote: >> >> How is ffff880000090000 both in the direct mapping and a slab object? > > I think this is just very regular /dev/mem behavior, that is hidden by > the fact that the *normal* case for /dev/mem is all to reserved RAM, > which will never be a slab object. > > And this is all hidden with STRICT_DEVMEM, which pretty much everybody > has enabled, but Tommi for some reason did not. (It tripped under Fedora (with STRICT_DEVMEM) too, but I see below you isolated it...) > >> It would need to pass all of these checks, and be marked as PageSlab >> before it could be evaluated by __check_heap_object: > > It trivially passes those checks, because it's a normal kernel address > for a page that is just used for kernel stuff. > > I think we have two options: > > - just get rid of STRICT_DEVMEM and make that unconditional I'm a fan of this whatever the case; have all the video drivers moved away from crazy userspace direct memory access? (Or am I misremembering the reason for allowing /dev/mem to read RAM?) > - make the read_mem/write_mem code use some non-checking copy > routines, since they are obviously designed to access any memory > location (including kernel memory) unless STRICT_DEVMEM is set. I don't think this is a probably with the usercopy code: it is attempting to read RAM which should be blocked. It just _happens_ that this RAM got used for slab cache. > Hmm. Thinking more about this, we do allow access to the first 1MB of > physical memory unconditionally (see devmem_is_allowed() in Oooh, yes, that's the issue here. If the location is bypassing devmem_is_allowed(), oops. > arch/x86/mm/init.c). And I think we only _reserve_ the first 64kB or > something. So I guess even STRICT_DEVMEM isn't actually all that > strict. > > So this should be visible even *with* STRICT_DEVMEM. > > Does a simple > > sudo dd if=/dev/mem of=/dev/null bs=4096 count=256 > > also show the same issue? Maybe regardless of STRICT_DEVMEM? > > Maybe we should change devmem_is_allowed() to return a ternary value, > and then have it be "allow access" (for reserved pages), "disallow > access" (for various random stuff), and "just read zero" (for pages in > the low 1M that aren't marked reserved). If that doesn't break x86info, that would be nice too. > That way things like that read the low 1M (like x86info) will > hopefully not be unhappy, but also won't be reading random kernel > data. So, this seems like an uncommon situation where <1M memory ended up in as regular RAM. It seems like this exception is the problem? -Kees -- Kees Cook Pixel Security