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