linux-kernel - Re: [PATCH] fs: make sure we do not read beyond allocation

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:	Thu, 3 Oct 2013 19:23:11 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Kees Cook <keescook@...omium.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/