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

[Rik van Riel]

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: signature.asc
Description: This is a digitally signed message part