On Wed, Aug 17, 2016 at 2:37 PM, Rik van Riel <[email protected]> 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
