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

Groups > linux.kernel > #1464833

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

Show all headers | View raw

On Wed, Aug 17, 2016 at 2:37 PM, Rik van Riel <riel@redhat.com> wrote:
> On Wed, 2016-08-17 at 09:14 -0700, Linus Torvalds wrote:
>
>> 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.
>
> I glossed over the fact that prep_new_page only marks
> the page as a compound page if __GFP_COMP is set, which
> it is not for some higher order allocations, including
> GFP masks passed straight through by the SLOB allocator.
>
> This particular allocation is through kmalloc, but the
> kernel in question has CONFIG_SLOB=y, and usercopy has
> no code in mm/slob.c

But PageSlab(page) should trip, returning __check_heap_object, which
for SLOB should just return NULL, skipping all the rest of the
checks...

-Kees

>
> I can think of two possibilities:
> - mark every higher order allocation so it can be
>   recognized later on (this might break allocators
>   that free part of a higher order allocation, I
>   do not know whether they exist)
> - drop this part of the usercopy code, and no longer
>   check that a range is part of an object that was
>   allocated all at once, or spans multiple memory
>   allocations - this may be ok, given that most
>   heap overflows are likely to be kmalloc/slab objects,
>   anyway
>
> kind regards,
>
> Rik
> --
>
> All Rights Reversed.



-- 
Kees Cook
Nexus Security

Back to linux.kernel | Previous | Next — Previous 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