Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 11 Apr 2016 12:08:57 -0700
From: Kees Cook <>
To: "" <>
Cc: lazytyped <>
Subject: Re: [RFC v2] mm: SLAB freelist randomization

On Sat, Apr 9, 2016 at 7:08 AM, lazytyped <> wrote:
> On 4/8/16 11:03 AM, Thomas Garnier wrote:
>> For example this attack against SLUB (also applicable against SLAB)
>> would be affected:
> would it?
> - allocate a ton of shmid_kernel until you get a fresh page
> - free one of such objects (here is where your randomization comes into
> play)
> - allocate the "vulnerable" object
> - trigger the overflow
> - start "freeing" the others - one will work
> This doesn't work only in the case in which you are the last object in
> the SLUB. So what you are achieving is a 1/(pagesize/sizeof_objects)
> chance of making the attack less reliable. But I can free yet another
> object and retry, if the previous overflow didn't kill me (simplest way
> to guarantee that is to not completely fill the newly allocated SLUB page).

All the randomization stuff is just a statistical defense, though it
would seem to raise the bar of exploitation. I'd love to get a solid
example for an exploit that this mitigation would interfere with,
though. Do you know of any that would fit better here?


Kees Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.