Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jan 2016 15:39:10 -0800
From: Kees Cook <>
To: Yves-Alexis Perez <>
Cc: "" <>, David Windsor <>
Subject: Re: [RFC PATCH v2 00/12] Add PAX_REFCOUNT overflow protection

On Wed, Jan 20, 2016 at 12:57 PM, Yves-Alexis Perez <> wrote:
> On mar., 2016-01-19 at 11:07 -0800, Kees Cook wrote:
>> Hi David,
>> On Thu, Dec 17, 2015 at 12:55 PM, Kees Cook <> wrote:
>> > On Thu, Dec 17, 2015 at 6:57 AM, David Windsor <> wrote:
>> > > NOTE: This is a v2 submission because patch 3/5 in v1 was too large to
>> > > sent
>> > > to kernel-hardening.  Taking that as a sign that the patch needed to be
>> > > split,
>> > > I'm sending this version of the patchset, with the patches split more or
>> > > less
>> > > on a per-maintainer basis (except for those in drivers/).
>> How's the next spin coming? It looks like we have some new real-world
>> examples of exploits that would have been blocked by this protection:
>> ernel-vulnerability-cve-2016-0728/
> One thing which is surprising (I have to admit I'm not really an expert on how
> SLAB works) is how easy it apparently is to have multiple allocations end up
> at the same place. You don't even have to *know* the exact address.
> Wouldn't it be possible to at least have some randomization here, so new
> object are not at the same place as the not-freed-ones, somehow preventing the
> use-after-free and forcing an attacker to do some heap massaging?

Yeah, it could be worth doing. Maybe Laura will want to take a stab at
this after the sanitization series is done?


Kees Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

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