lkml.org 
[lkml]   [2013]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs: make sure we do not read beyond allocation
On Thu, Oct 03, 2013 at 11:03:07AM -0700, Kees Cook wrote:

> > When you start a port to a 512-bit architecture, you'll have much nastier
> > problems than this one...
>
> Well, this is simply taking advantage of this particular allocator's
> behavior. Instead of depending on this side-effect, why not change the
> allocation so that we never risk a potentially broken read? (Even SLOB
> notes that it may have as low as 2-byte granularity.)

Oh, for fuck sake! "Hardening", indeed...

Kees, try to think for a minute[1]. Really. We have general-purpose
allocator. Asked to give us something considerably bigger than one
word. How do you call a situation when it returns something with
the end of requested object crossing the page boundary if rounded
up to nearest multiple of word size?

That's right, FUBAR. Because for that to happen it would have to
have given you an address that would not be word-aligned. In response
to request to allocate something wider than a word. Remember the
words along the lines of "the pointer returned if the allocation
succeeds is properly aligned..."?

It's not a behaviour of this particular allocator. It's something that
will have to be guaranteed by *any* general-purpose allocator.

[1] yes, yes, I know - the mere mention of security should've prevented such
arrogant requests. It's an imperfect universe.


\
 
 \ /
  Last update: 2013-10-03 20:41    [W:0.062 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site