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

[Rik van Riel <riel@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

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

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]