From: Pekka Enberg <penberg@kernel.org>
To: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Matt Mackall <mpm@selenic.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Theodore Tso <tytso@mit.edu>,
cl@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Make /proc/slabinfo 0400
Date: Fri, 4 Mar 2011 23:30:55 +0200 [thread overview]
Message-ID: <AANLkTina+O77BFV+7mO9fX2aJimpO0ov_MKwxGtMwqG+@mail.gmail.com> (raw)
In-Reply-To: <1299272907.2071.1415.camel@dan>
Hi Dan,
[ Thanks to you and Matt for taking the time to explain this to me. ]
On Fri, Mar 4, 2011 at 11:08 PM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> I could be mistaken on this, so feel free to correct me. What if you
> just fill more than one slab with the object you'd like to overflow
> into, then pick an object that's guaranteed to reside in a slab filled
> with your objects. Upon freeing that object and allocating a new
> to-be-overflowed object (that's sized so it's handled by the same slab
> cache), this new object will be guaranteed to be sitting immediately
> before one of your objects (or before the end of the slab if you're
> unlucky). You can still win because it doesn't matter which specific
> object you overflow, only that you overflow one of them.
Right. So you fill a slab with objects A that you want to overflow
(struct shmid_kernel in the example exploit) then free one of them,
allocate object B, smash it (and the next object), and find the
smashed object A.
But doesn't that make the whole /slab/procinfo discussion moot? You
can always use brute force to allocate N objects (where N is larger
than max objects in a slab) and then just free nth object that's most
likely to land on the slab you have full control over (as explained by
Matt).
Pekka
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-04 21:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-03 17:50 Dan Rosenberg
2011-03-03 18:17 ` Dave Hansen
2011-03-03 18:29 ` Dan Rosenberg
2011-03-03 20:58 ` Matt Mackall
2011-03-03 21:16 ` Dan Rosenberg
2011-03-03 21:44 ` Matt Mackall
2011-03-03 22:30 ` Dan Rosenberg
2011-03-03 23:08 ` Matt Mackall
2011-03-04 0:32 ` Dave Hansen
2011-03-04 0:50 ` Theodore Tso
2011-03-04 6:52 ` Pekka Enberg
2011-03-04 17:36 ` Dave Hansen
2011-03-04 17:48 ` Linus Torvalds
2011-03-04 18:14 ` Matt Mackall
2011-03-04 20:02 ` Pekka Enberg
2011-03-04 20:31 ` Matt Mackall
2011-03-04 20:42 ` Dan Rosenberg
2011-03-04 20:56 ` Pekka Enberg
2011-03-04 21:08 ` Dan Rosenberg
2011-03-04 21:30 ` Pekka Enberg [this message]
2011-03-04 21:44 ` Dan Rosenberg
2011-03-04 22:10 ` Pekka Enberg
2011-03-04 22:14 ` Pekka Enberg
2011-03-04 23:02 ` Matt Mackall
2011-03-05 16:25 ` Ted Ts'o
2011-03-06 13:19 ` Alan Cox
2011-03-07 14:56 ` Dan Rosenberg
2011-03-07 16:02 ` Matt Mackall
2011-03-04 20:37 ` Dan Rosenberg
2011-03-04 20:58 ` Pekka Enberg
2011-03-04 21:10 ` Dan Rosenberg
2011-03-06 0:42 ` Jesper Juhl
2011-03-06 0:57 ` Dan Rosenberg
2011-03-06 1:09 ` Matt Mackall
2011-03-06 1:15 ` Jesper Juhl
2011-03-07 16:40 ` Christoph Lameter
2011-03-04 21:12 ` Matt Mackall
2011-03-04 11:58 ` Alan Cox
2011-03-07 14:19 [PATCH] Make /proc/slabinfo 040 George Spelvin
2011-03-07 17:49 ` [PATCH] Make /proc/slabinfo 0400 George Spelvin
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=AANLkTina+O77BFV+7mO9fX2aJimpO0ov_MKwxGtMwqG+@mail.gmail.com \
--to=penberg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=drosenberg@vsecurity.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=mpm@selenic.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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