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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Aug 2016 14:45:43 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	kernel test robot <xiaolong.ye@...el.com>, LKP <lkp@...org>,
	LKML <linux-kernel@...r.kernel.org>,
	Valdis Kletnieks <valdis.kletnieks@...edu>
Subject: Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75!

On Wed, Aug 17, 2016 at 2:37 PM, Rik van Riel <riel@...hat.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