Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1614335

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

Show all headers | View raw

On Fri, Mar 31, 2017 at 11:26 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Mar 31, 2017 at 10:32 AM, Kees Cook <keescook@chromium.org> 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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-03-30 18:50 +0200
  Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Laura Abbott <labbott@redhat.com> - 2017-03-30 19:30 +0200
    Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-03-30 19:40 +0200
      Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Laura Abbott <labbott@redhat.com> - 2017-03-30 19:50 +0200
  Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Mark Rutland <mark.rutland@arm.com> - 2017-03-30 19:30 +0200
  Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Dave Jones <davej@codemonkey.org.uk> - 2017-03-30 21:50 +0200
    Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-03-30 22:00 +0200
      Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Dave Jones <davej@codemonkey.org.uk> - 2017-03-30 22:10 +0200
      Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Dave Jones <davej@codemonkey.org.uk> - 2017-03-31 19:20 +0200
        Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-03-31 19:40 +0200
          Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Dave Jones <davej@codemonkey.org.uk> - 2017-03-31 20:10 +0200
            Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Andy Lutomirski <luto@amacapital.net> - 2017-03-31 21:00 +0200
          Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-31 20:30 +0200
            Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-04-01 02:00 +0200
            Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-04-05 00:40 +0200
              Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Linus Torvalds <torvalds@linux-foundation.org> - 2017-04-05 01:00 +0200
                Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-04-05 01:10 +0200
                Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Linus Torvalds <torvalds@linux-foundation.org> - 2017-04-05 02:30 +0200
                Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Kees Cook <keescook@chromium.org> - 2017-04-05 21:40 +0200

csiph-web