linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH] fs: make sure we do not read beyond allocation
Date: Thu, 3 Oct 2013 19:23:11 +0100	[thread overview]
Message-ID: <20131003182311.GI13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAGXu5j+8sxc8vc4bwv14nGNiOhq-ey2nxAK99LgMKO+Qmh1L6A@mail.gmail.com>

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.

  reply	other threads:[~2013-10-03 18:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 16:34 [PATCH] fs: make sure we do not read beyond allocation Kees Cook
2013-10-03 17:58 ` Al Viro
2013-10-03 18:03   ` Kees Cook
2013-10-03 18:23     ` Al Viro [this message]
2013-10-03 19:36       ` Kees Cook
2013-10-03 20:57         ` Al Viro
2013-10-03 21:30           ` Kees Cook
2013-10-04  6:05           ` Dmitry Vyukov
2013-10-04 10:38             ` Richard Weinberger
2013-10-04 10:53               ` Dmitry Vyukov
2013-10-04 13:53                 ` Richard Weinberger
2013-10-11 11:26                   ` Dmitry Vyukov
2013-10-11 11:27                     ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131003182311.GI13318@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=dvyukov@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).