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]

Message-ID: <1471469820.32433.74.camel@redhat.com>
Date:	Wed, 17 Aug 2016 17:37:00 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	kernel test robot <xiaolong.ye@...el.com>
Cc:	Kees Cook <keescook@...omium.org>, 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, 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.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)