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


Groups > linux.kernel > #1464643

Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75!

From Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups linux.kernel
Subject Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75!
Date 2016-08-17 18:20 +0200
Message-ID <s7bJo-3pe-19@gated-at.bofh.it> (permalink)
References <s77Z7-TF-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Aug 17, 2016 at 5:17 AM, kernel test robot
<xiaolong.ye@intel.com> wrote:
>
> [  177.875629] usercopy: kernel memory overwrite attempt detected to 80028f40 (<spans multiple pages>) (512 bytes)

Ugh. This is a bug in the memory access hardening code.

I think it's this:

                        err = __copy_from_user(&fpu->state.xsave,
                                               buf_fx, state_size);

where it's copying the xsave area into the kernel buffer. That fpu
buffer is part of the thread structure:

                struct fpu *fpu = &tsk->thread.fpu;

and the thread struct allocation is two pages at 80028000:

> [  178.037761] task: 80028000 ti: 8002a000 task.ti: 8002a000

So yes, it "crosses" the page from 80028000 to 80029000, but the task
allocation is fine, at 80028000-8002a000.

The check_heap_object() code is simply buggy. It does seem to try to
handle this, by handling compound pages:

        /* Allow if start and end are inside the same compound page. */
        endpage = virt_to_head_page(end);
        if (likely(endpage == page))
                return NULL;

but compound pages are about the mapping of hugepages, not about
simple multi-order allocations like the task structure (or slab
entries).

In other words, it looks like the memory hardening is simply broken
for any case that doesn't use kmalloc(), but instead just allocates
non-order-0 pages directly. Which is certainly _rare_, but not unheard
of.

I'm not sure how to fix it.The low-level page allocator does *not*
mark orders anywhere.

I suspect we should just get rid of the page-crosser checking, because
it's unsolvable.

                  Linus

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


Thread

Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-17 18:20 +0200
  Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Kees Cook <keescook@chromium.org> - 2016-08-17 23:30 +0200
    Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Kees Cook <keescook@chromium.org> - 2016-08-17 23:40 +0200
    Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-17 23:40 +0200
  Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Rik van Riel <riel@redhat.com> - 2016-08-17 23:50 +0200
    Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-18 00:00 +0200
      Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Kees Cook <keescook@chromium.org> - 2016-08-18 00:00 +0200
        Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-18 00:00 +0200
          Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Kees Cook <keescook@chromium.org> - 2016-08-18 00:00 +0200
    Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Kees Cook <keescook@chromium.org> - 2016-08-18 00:00 +0200
    Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-18 00:00 +0200
    Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Kees Cook <keescook@chromium.org> - 2016-08-18 00:00 +0200

csiph-web